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A computer-implemented system and method for generating a 
hardware implementation of graphical code. Hie method comprises first 
creating a graphical program. A first portion of the graphical program 
may optionally be compiled into machine code for execution by a CPU. 
A second portion of the graphical program is converted into a hardware 
implementation according to the present invention. The opertion 
of converting the graphical program into a hardware implementation 
comprises exporting the second portion of the graphical program into 
a hardware description, wherein the hardware description describes a 
hardware implementation of the second portion of the graphical program, 
and then configuring a programmable hardware element utilizing the 
hardware description to produce a configured hardware element The 
configured hardware element thus implements a hardware implementation 
of the second portion of the graphical program. 
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System and Method for Converting Graphical Programs into Hardware Implementations 



Reservation of Copyright 

5 

A portion of the disclosure of this patent document contains material to which a claim of copyright 
protection is made. The copyright owner has no objection to the facsimile reproduction by anyone of the patent 
document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but 
reserves all other rights whatsoever. 

10 

Field of the Invention 

The present invention relates to graphical programming, and in particular to a system and method for 
converting a graphical program into a programmable hardware implementation. 

1 5 Description of the Related Art 

Traditionally, high level text-based programming languages have been used by programmers in writing 
applications programs. Many different high level programming languages exist including BASIC, C, FORTRAN, 
Pascal, COBOL, ADA, APL, etc. Programs written in these high level languages are translated to the machine 
language level by translators known as compilers. The high level programming languages in this level, as well as 

20 the assembly language level, are referred to as text-based programming environments. 

Increasingly computers are required to be used and programmed by those who are not highly trained in 
computer programming techniques. When traditional text-based programming environments are used, the user's 
programming skills and ability to interact with the computer system often become a limiting factor in the 
achievement of optimal utilization of the computer system. 

25 There are numerous subtle complexities which a user must master before he can efficiently program a 

computer system in a text-based environment. The task of programming a computer system to model a process 
often is further complicated by the fact that a sequence of mathematical formulas, mathematical steps or other 
procedures customarily used to conceptually model a process often does not closely correspond to the traditional 
text-based programming techniques used to program a computer system to model such a process. In other words, 

30 the requirement that a user program in a text-based programming environment places a level of abstraction between 
the user's conceptualization of the solution and the implementation of a method that accomplishes this solution in a 
computer program. Thus, a user often must substantially master different skills in order to both conceptually model 
a system and then to program a computer to model that system. Since a user often is not fully proficient in 
techniques for programming a computer system in a text-based environment to implement his model, the efficiency 

35 with which the computer system can be utilized to perform such modeling often is reduced. 

Examples of fields in which computer systems are employed to model and/or control physical systems are 
the fields of instrumentation, process control, and industrial automation. Computer modeling or control of devices 
such as instruments or industrial automation hardware has become increasingly desirable in view of the increasing 
complexity and variety of instruments and devices available for use. However, due to the wide variety of possible 

40 testing/control situations and environments, and also the wide array of instruments or devices available, it is often 

1 
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necessary for a user to develop a program to control a desired system. As discussed above, computer programs 
used to control such systems had to be written in conventional text-based programming languages such as, for 
example, assembly language, C, FORTRAN, BASIC, or Pascal. Traditional users of these systems, however, often 
were not highly trained in programming techniques and, in addition, traditional text-based programming languages 
5 were not sufficiently intuitive to allow users to use these languages without training. Therefore, implementation of 
such systems frequently required the involvement of a programmer to write software for control and analysis of 
instrumentation or industrial automation data. Thus, development and maintenance of the software elements in 
these systems often proved to be difficult. 

U.S. Patent Number 4,901,221 to Kodosky et al discloses a graphical system and method for modeling a 

1 0 process, i.e. a graphical programming environment which enables a user to easily and intuitively model a process. 
The graphical programming environment disclosed in Kodosky et al can be considered the highest and most 
intuitive way in which to interact with a computer. A graphically based programming environment can be 
represented at level above text-based high level programming languages such as C, Pascal, etc. The method 
disclosed in Kodosky et al allows a user to construct a diagram using a block diagram editor, such that the diagram 

15 created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or 
more input variables to produce one or more output variables. In response to the user constructing a data flow 
diagram or graphical program using the block diagram editor, machine language instructions are automatically 
constructed which characterize an execution procedure which corresponds to the displayed procedure. Therefore, a 
user can create a computer program solely by using a graphically based programming environment. This 

20 graphically based programming environment may be used for creating virtual instrumentation systems, industrial 
automation systems and modeling processes, as well as for any type of general programming. 

Therefore, Kodosky et al teaches a graphical programming environment wherein a user places on 
manipulates* icons in a block diagram using a block diagram editor to create a data flow "program." A graphical 
program for controlling or modeling devices, such as instruments, processes or industrial automation hardware, is 

25 referred to as a virtual instrument (VI). In creating a virtual instrument, a user preferably creates a front panel or 
user interface panel. The front panel includes various front panel objects, such as controls or indicators that 
represent the respective input and output that will be used by the graphical program or VI, and may include other 
icons which represent devices being controlled. When the controls and indicators are created in the front panel, 
corresponding icons or terminals are automatically created in the block diagram by the block diagram editor. 

30 Alternatively, the user can first place terminal icons in the blocK diagram which cause the display of corresponding 
front panel objects in the front panel. The user then chooses various functions that accomplish his desired result, 
connecting the corresponding function icons between the terminals of the respective controls and indicators. In 
other words, the user creates a data flow program, referred to as a block diagram, representing the graphical data 
flow which accomplishes his desired function. This is done by wiring up the various function icons between the 

35 control icons and indicator icons. The manipulation and organization of icons in turn produces machine language 
that accomplishes the desired method or process as shown in the block diagram. 

A user inputs data to a virtual instrument using front panel controls. This input data propagates through 
the data flow block diagram or graphical program and appears as changes on the output indicators. In an 
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instrumentation application, the front panel can be analogized to the front panel of an instrument. In an industrial 
automation application the front panel can be analogized to the MMI (Man Machine Interface) of a device. The 
user adjusts the controls on the front panel to affect the input and views the output on the respective indicators. 
Thus, graphical programming has become a powerful tool available to programmers. Graphical 
5 programming environments such as ilie National Instruments LabVIEW product have become very popular. Tools 
such as LabVIEW have greatly increased the productivity of programmers, and increasing numbers of 
programmers are using graphical programming environments to develop their software applications. In particular, 
graphical programming tools are being used for test and measurement, data acquisition, process control, man 
machine interface (MMI), and supervisory control and data acquisition (SCADA) applications, among others. 
10 A primary goal of virtual instrumentation is to provide the user the maximum amount of flexibility to 

create his/her own applications and/or define his/her own instrument functionality. In this regard, it is desirable to 
extend the level at which the user of instrumentation or industrial automation hardware is able to program 
instrument. The evolution of the levels at which the user has been able to program an instrument is essentially as 
follows. 

15 1 . User level software (LabVIEW, LabWindows CVI, Visual Basic, etc.) 

2. Kernel level software 

3. Auxiliary kernel level software (a second kernel running along side the main OS, e.g., InTime, 
VentureCom, etc.) 

4. Embedded kernel level software 

20 5. Hardware level software (FPGA - the present patent application) 



In general, going down the above list, the user is able to create software applications which provide a more 
deterministic real-time response. Currently, most programming development tools for instrumentation or industrial 
automation provide an interface at level 1 above. In general, most users are unable and/or not allowed to program 

25 at the kernel level or auxiliary kernel Sevel. The user level software typically takes the form of software tools that 
can be used to create software which operates at levels 1 and/or 4. 

Current instrumentation solutions at level 5 primarily exist as vendor-defined solutions, i.e., vendor 
created modules. However, it would be highly desirable to provide the user with the ability to develop user level 
software which operates at the hardware level. More particularly, it would be desirable to provide the user with the 

30 ability to develop high level software, such as graphical programs, which can then be readily converted into 
hardware level instrument functionality. This would provide the user with the dual benefits of being able to 
program instrument functionality at the highest level possible (text-based or graphical programs), while also 
providing the ability to have the created program operate directly in hardware for increased speed and efficiency. 

35 Summary of the Invention 

The present invention comprises a computer-implemented system and method for automatically generating 
hardware level functionality, e.g., programmable hardware or FPGAs, in response to a graphical program created 
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by a user. This provides the user the ability to develop or define instrument functionality using graphical 
programming techniques, while enabling the resulting program to operate directly in hardware. 

The user first creates a graphical program which performs or represents the desired functionality. The 
graphical program will typically include one or more modules or a hierarchy of sub- Vis. In the preferred 
5 embodiment, the user places various constructs in portions of the graphical program to aid in conversion of these 
portions into hardware form. 

The user then selects an option to convert the graphical program into executable form, wherein at least a 
portion of the graphical program is converted into a hardware implementation. According to one embodiment of the 
present invention, the user can select which portions of modules are to be translated into hardware form, either 

10 during creation of the graphical program or when selecting the option to convert the graphical program into 
executable form. Thus the user can select a first portion of the graphical program, preferably comprising the 
supervisory control and display portion of the program, to be compiled into machine language for execution on a 
CPU. According to the present invention, the user can select a second portion of the graphical program which is 
desired for hardware implementation. 

1 5 The portion of the graphical program selected for hardware implementation is first exported into a 

hardware description, such as a VHDL description. The hardware description is then converted into a net list, 
preferably an FPGA-specific net list. The hardware description is converted into a net list by a synthesis tool. The 
net list is then compiled into a FPGA program file, also called a software bit stream. In the preferred embodiment, 
the hardware description is directly converted into an FPGA program file. 

20 The step of compiling the resulting net list into an FPGA program file preferably uses a library of pre- 

compiled function blocks to aid in the compilation, as well as hardware target specific information. The library of 
pre-compiled function blocks includes net list libraries for structure nodes, such as for/next loops, while/do loops, 
case structures, and sequence structures, among others. This allows the user to program with high level 
programming constructs, such as iteration, looping, and case structures, while allowing the resulting program to 

25 execute directly in hardware. 

The resulting bit stream is then transferred to an FPGA to produce a programmed FPGA equivalent to the 
graphical program or block diagram. 

The preferred embodiment of the invention comprises a general purpose computer system which includes 
a CPU and memory, and an interface card or device coupled to the computer system which includes programmable 

30 hardware or logic, such as an FPGA. The computer system includes a graphical programming system which is 
used to develop the graphical program. The computer system also includes software according to the present 
invention which is operable to convert the graphical program into a hardware description. The computer system 
further includes a synthesis tool which is used to compile the hardware description into an FPGA-specific net list, 
as well as other tools for converting the net list into an FPGA program file for downloading into the FPGA. The 

35 computer system further includes a library of pre-compiled function blocks according to the present invention 
which are used by the synthesis tool to aid in compiling the net list into the software bit stream. 

In one embodiment, the target device including the reconfigurable hardware or FPGA being programmed 
comprises an interface card in the computer system, such as a data acquisition card, a GPIB interface card, or a VXI 
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interface card. In an alternate embodiment, the target device being programmed comprises an instrument or device 
connected to the computer, such as through a serial connection. It is noted that the target instrument or device 
being programmed, which includes an FPGA or other configurable hardware element, can take any of various 
forms, as desired. 

5 

Brief Description of the Drawings 

A better understanding of the present invention can be obtained when the following detailed description of 
the preferred embodiment is considered in conjunction with the following drawings, in which: 

Figure 1 illustrates an instrumentation control system; 
10 Figure 1A illustrates an industrial automation system; 

Figure 2 is a block diagram of the instrumentation control system of Figure 1; 

Figures 3, 3A and 3B are block diagrams illustrating an interface card configured with programmable 
hardware according to various embodiments of the present invention; 

Figure 4 is a flowchart diagram illustrating operation of the present invention; 
15 Figure 4A is a more detailed flowchart diagram illustrating operation of the preferred embodiment of the 

invention, including compiling a first portion of the graphical program into machine language and converting a 
second portion of the graphical program into a hardware implementation; 

Figure 5 is a more detailed flowchart diagram illustrating creation of a graphical program according to the 
preferred embodiment: 

20 Figure 6 is a more detailed flowchart diagram illustrating operation of exporting at least a portion of a 

graphical program to a hardware description; 

Figure 7 is a flowchart diagram illustrating operation where the method exports an input terminal into a 
hardware description; 

Figure 8 is a flowchart diagram illustrating operation where the method exports a function node into a 
25 hardware description; 

Figure 9 is a flowchart diagram illustrating operation where the method exports an output terminal into a 
hardware description; 

Figure 10 is a flowchart diagram illustrating operation where the method exports a structure node into a 
hardware description; 

30 Figure 1 1 illustrates converting a node hardware description to a net list; 

Figure 12 illustrates converting a structure node hardware description to a net list; 
Figure 13 illustrates the function block for a structure node; 

Figure 14 is a state diagram illustrating operation of the structure node function block of Figure 13; 

Figures 15 and 16 illustrate a simple example of operation of the present invention, wherein Figure 15 
35 illustrates a simple graphical program and Figure 16 is a conceptual diagram of the hardware description of the 
graphical program of Figure 15; 

Figures 17-19 illustrate another example of operation of the present invention, wherein Figure 17 
illustrates a graphical program, Figure 18 illustrates a tree of data structures created in response to the graphical 
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program of Figure 17, and Figure 18 is a conceptual diagram of the hardware description of the graphical program 
of Figure 17; and 

Figures 20-21 illustrate a graphical program called examplel.vi. 

5 While the invention is susceptible to various modifications and alternative forms specific embodiments are 

shown by way of example in the drawings and will herein be described in detail It should be understood however, 
that drawings and detailed description thereto are not intended to limit the invention to the particular form 
disclosed. But on the contrary the invention is to cover all modifications, equivalents and alternative following 
within the spirit and scope of the present invention as defined by the appended claims. 

10 

Detailed Description of the Preferred Embodiment 

Figures 1 and 1 A - Instrumentation and Industrial Automation Systems 

Referring now to Figure 1, an instrumentation control system 100 is shown. The system 100 comprises a 
computer 102 which connects to one or more instruments. The computer 102 comprises a CPU, a display screen, 

15 memory, and one or more input devices such as a mouse or keyboard as shown. The computer 102 connects through 
the one or more instruments to analyze, measure or control a unit undo* test (UUT) or process 130. 

The one or more instruments may include a GPIB instrument 1 12, a data acquisition board 1 14, and/or a VXI 
instrument 1 16. The GPIB instrument 1 12 is coupled to the computer 102 via a GPIB interface card 122 provided by 
the computer 102. The data acquisition board 1 14 is coupled to the computer 102, and preferably interfaces through 

20 signal conditioning circuitry 124 to the UUT. The signal conditioning circuitry 124 preferably comprises an SCXI 
(Signal Conditioning extensions for Instrumentation) chassis comprising one or more SCXI modules 126. Both the 
GPIB card 122 and the DAQ card 1 14 are typically plugged in to an I/O slot in the computer 102, such as a PCI bus 
slot, a PC Card slot, or an ISA, EISA or MicroChannel bus slot provided by the computer 102. However, these cards 
122 and 1 14 are shown external to computer 102 for illustrative purposes. The VXI instrument 1 16 is coupled to the 

25 computer 1 02 via a VXI bus, MXI bus, or other serial or parallel bus provided by the computer 102. The computer 

102 preferably includes VXI interface logic, such as a VXI, MXI or GPIB interface card (not shown) comprised in the 
computer. A serial instrument (not shown) may also be coupled to the computer 102 through a serial port, such as an 
RS-232 port, USB (Universal Serial bus) or IEEE 1394 or 1394.2 bus, provided by the computer 102. In typical 
instrumentation control systems an instrument will not be present of each interface type, and in fact many systems may 

30 only have one or more instruments of a single interface type, such as only GPIB instruments. 

In the embodiment of Figure 1 , one or more of the devices connected to the computer 1 02 include 
programmable or reconfigurable hardware according to the present invention. For example, one or more of the GPIB 
card 122, the DAQ card 1 14, or the VXI card include programmable hardware according to the present invention. 
Alternatively, or in addition, one or more of the GPIB instrument 1 12, the VXI instrument 1 16, or the serial instrument 

35 include programmable hardware according to the present invention. In the preferred embodiment, the programmable 
hardware comprises an FPGA (field programmable gate array). 
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The instruments are coupled to the unit under test (UUT) or process 130, or are coupled to receive field 
signals, typically generated by transducers. The system 100 may be used in a data acquisition and control application, 
in a test and measurement application, a process control application, or a man-machine interface application. 

Referring now to Figure 1 A, an industrial automation system 140 is shown. The industrial automation system 
5 1 40 is similar to the instrumentation or test and measurement system 1 00 shown in Figure 1 , Elements which are 
similar or identical to elements in Figure 1 have the same reference numerals for convenience. The system 140 
comprises a computer 102 which connects to one or more devices or instruments. The computer 102 comprises a 
CPU, a display screen, memory, and one or more input devices such as a mouse or keyboard as shown. The computer 
102 connects through the one or more devices to a process or device 160 to perform an automation function, such as 

1 0 MMI (Man Machine Interface), SCADA (Supervisory Control and Data Acquisition), portable or distributed 
acquisition, advanced analysis, or control 

The one or more devices may include a data acquisition board 1 14, a serial instrument 142, a PLC 
(Programmable Logic Controller) 144, or a fieldbus network card 156. The data acquisition board 1 14 is coupled to or 
comprised in the computer 102, and preferably interfaces through signal conditioning circuitry 124 to the process 160. 

15 The signal conditioning circuitry 124 preferably comprises an SCXI (Signal Conditioning extensions for 

Instrumentation) chassis comprising one or more SCXI modules 126. The serial instrument 142 is coupled to the 
computer 102 through a serial interface card 152, or through a serial port, such as an RS-232 port, provided by the 
computer 102. The PLC 144 couples to the computer 102 through a serial port, Ethernet port, or a proprietary 
interface. The fieldbus interface card 156 is preferably comprised in the computer 102 and interfaces through a 

20 fieldbus network to one or more fieldbus devices, such as valve 146. Each of the DAQ card 1 14, the serial card 1 52 
and the fieldbus card 1 56 are typically plugged in to an I/O slot in the computer 102 as described above. However, 
these cards 114, 12 and 156 are shown external to computer 102 for illustrative purposes. In typical industrial 
automation systems a device will not be present of each interface type, and in fact many systems may only have one or 
more devices of a single interface type, such as only PLCs. The devices are coupled to the device or process 160. 

25 In the embodiment of Figure 1 A, one or more of the devices connected to the computer 102 include 

programmable hardware according to the present invention. For example, one or more of the data acquisition board 
1 14, the serial instrument 142, the serial interface card 152, the PLC 144, or the fieldbus network card 156 include 
programmable hardware according to the present invention. In the preferred embodiment, the programmable hardware 
comprises an FPGA (field programmable gate array). 

30 Referring again to Figures 1 and 1 A, the computer 1 02 preferably includes a memory media, such as a non- 

volatile media, e.g., a magnetic media, CD-ROM, or floppy disks 104, or a volatile media, such as computer system 
memory, e.g., random access memory (RAM). The memory media preferably stores a graphical programming 
development system for developing graphical programs. The memory media also stores computer programs according 
to the present invention which are executable to convert at least a portion of a graphical program into a form for 

35 configuring or programming the programmable hardware or FPGA. The present invention includes a software 

program stored on a memory and/or hard drive of the computer 102 and executed by a CPU of the computer 102. 
The CPU executing code and data from the memory thus comprises a means for converting graphical code into a 
hardware implementation according to the steps described below. 
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The instruments or devices in Figures 1 and 1 A are controlled by graphical software programs, optionally a 
portion of which execute on the CPU of the computer 102, and at least a portion of which are downloaded to the 
programmable hardware for hardware execution. The graphical software programs which perform data acquisition, 
analysis and/or presentation, e.g., for instrumentation control or industrial automation, are referred to as virtual 
instruments. 

In the preferred embodiment, the present invention is comprised in the Lab VIEW or BridgeVIEW graphical 
programming systems, hereafter collectively referred to as LabVIEW, available from National Instruments. Also, in 
the preferred embodiment, the term "LabVIEW" is intended to include graphical programming systems which include 
G programming functionality, i.e., which include at least a portion of LabVIEW graphical programming functionality, 
including the BridgeVIEW graphical programming system. 

Also, the term "graphical programming system" is intended to include any of various types of systems which 
are used to develop or create graphical code or graphical programs, including LabVIEW and BridgeVIEW from 
National Instruments, Visual Designer from Intelligent Instrumentation, Hewlett-Packard's VEE (Visual 
Engineering Environment), Snap-Master by HEM Data Corporation, DASYLab by DasyTec, GFS DiaDem, and . 
ObjectBench by SES (Scientific and Engineering Software), among others. 

Although in the preferred embodiment the graphical programs and programmable hardware are involved with 
data acquisition/generation, analysis, and/or display, and for controlling or modeling instrumentation or industrial 
automation hardware, it is noted that the present invention can be used to create hardware implementations of graphical 
programs for a plethora of applications and are not limited to instrumentation or industrial automation applications. In 
other words, Figures 1 and 1 A are exemplary only, and the present invention may be used in any of various types of 
systems. Thus, the system and method of the present invention is operable for automatically creating hardware 
implementations of graphical programs or graphical code for any of various types of applications, including general 
purpose software applications such as word processing, spreadsheets, network control, games, etc. 

Computer Block Diagram 

Referring now to Figure 2, a block diagram of the computer 1 02 (of Figure 1 ) is shown. The elements of a 
computer not necessary to understand the operation of the present invention have been omitted for simplicity. The 
computer 102 includes at least one central processing unit or CPU 160 which is coupled to a processor or host bus 
1 62. The CPU 160 may be any of various types, including an x86 processor, a PowerPC processor, a CPU from the 
Motorola family of processors, a CPU from the SPARC family of RISC processors, as well as others. Main 
memory 166 is coupled to the host bus 162 by means of memory controller 164. The main memory 166 stores a 
graphical programming system, and also stores software for converting at least a portion of a graphical program 
into a hardware implementation. This software will be discussed in more detail below. The main memory 166 also 
stores operating system software as well as the software for operation of the computer system, as well known to 
those skilled in the art. 

The host bus 162 is coupled to an expansion or input/output bus 170 by means of a bus controller 168 or 
bus bridge logic. The expansion bus 170 is preferably the PCI (Peripheral Component Interconnect) expansion bus, 
although other bus types can be used. The expansion bus 170 includes slots for various devices such as the data 
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acquisition board 1 14 (of Figure 1), a GPIB interface card 122 which provides a GPIB bus interface to the GPIB 
instrument 1 12 (of Figure 1), and a VXI or MXI bus card 230 coupled to the VXI chassis 1 16 for receiving VXI 
instruments. The computer 102 further comprises a video display subsystem 1 80 and hard drive 1 82 coupled to the 
expansion bus 1 70. 

5 One or more of the interface cards or devices coupled to the expansion bus, such as the DAQ card 1 14, the 

GPIB interface card 122, the GPIB instrument 1 12, or the VXI or MXI bus card 230 comprises an embedded 
system comprising an embedded CPU and embedded memory. 

Programmable Hardware Diagram 

10 Referring now to Figure 3, a block diagram illustrating an interface card configured with programmable 

hardware according to the present invention is shown. It is noted that Figure 3 is exemplary only, and an interface 
card or device configured with programmable hardware according to the present invention may have various 
architectures or forms, as desired. The interface card illustrated in Figure 3 is the DAQ interface card 1 14 shown in 
either of Figures 1 or 1 A. However, as noted above, the programmable hardware may be included on any of the 

15 various devices shown in Figures 1 or 1 A, or on other devices, as desired. 

As shown, the interface card 1 14 includes an I/O connector 202 which is coupled for receiving signals. In 
the embodiments of Figures 1 and 1 A, the I/O connector 202 presents analog and/or digital connections for 
receiving/providing analog or digital signals. The I/O connector 202 is adapted for coupling to SCXI conditioning 
logic 124 and 126, or is adapted to be coupled directly to a unit under test 130 or process 160. 

20 The interface card 1 14 also includes data acquisition (DAQ) logic 204. As shown, the data acquisition 

logic 204 comprises analog to digital (A/D) converters, digital to analog (D/A) converters, timer counters (TC) and 
signal conditioning (SC) logic as shown. The DAQ logic 204 provides the data acquisition functionality of the 
DAQ card 114. 

According to the preferred embodiment of the invention, the interface card 1 14 includes a programmable 
25 hardware element or programmable processor 206. In the preferred embodiment, the programmable hardware 206 
comprises a .field programmable gate array (FPGA) such as those available from Xilinx, Altera, etc. The 
programmable hardware element 206 is coupled to the DAQ logic 204 and is also coupled to the local bus interface 
208. Thus a graphical program can be created on the computer 102, or on another computer in a networked system, 
and at least a portion of the graphical program can be converted into a hardware implementation form for execution 
30 in the FPGA 206. The portion of the graphical program converted into a hardware implementation form is 
preferably a portion which requires fast and/or real-time execution 

In the embodiment of Figure 3, the interface card 1 14 further includes a dedicated on-board 
microprocessor 212 and memory 214. This enables a portion of the graphical program to be compiled into machine 
language for storage in the memory 214 and execution by the microprocessor 212. This is in addition to a portion 
35 of the graphical program being converted into a hardware implementation form in the FPGA 206. Thus, in one 
embodiment, after a graphical program has been created, a portion of the graphical program is compiled for 
execution on the embedded CPU 212 and executes locally on the interface card 1 14 via the CPU 212 and memory 
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214, and a sfecond portion of the graphical program is translated or converted into a hardware executable format and 

downloaded to the FPGA 206 for hardware implementation. 

As shown, the interface card 1 14 further includes bus interface logic 216 and a control/data bus 218. In 
the preferred embodiment, the interface card 1 14 is a PCI bus-compliant interface card adapted for coupling to the 
5 PCI bus of the host computer 1 02, or adapted for coupling to a PXI (PCI extensions for Instrumentation) bus. The 
bus interface logic 2 1 6 and the control/data bus 2 1 8 thus present a PCI or PXI interface. 

The interface card 1 14 also includes local bus interface logic 208. In the preferred embodiment, the local 
bus interface logic 208 presents a RTSI (Real Time System Integration) bus for routing timing and trigger signals 
between the interface card 1 14 and one or more other devices or cards. 
10 In one embodiment, the interface card 1 14 also includes a non-volatile memory 215 coupled to the 

programmable hardware element 206. The non-volatile memory is operable to store the hardware description 
received from the host computer system to enable execution of the hardware description in the programmable 
hardware element 206 prior to or during booting of the computer system 1 02. 

In the embodiment of Figure 3 A, the CPU 212 and memory 214 are not included on the interface card 1 14, 
15 and thus only the portion of the graphical program which is converted into hardware implementation form is 
downloaded' to the FPGA 206. Thus in the embodiment of Figure 3A, any supervisory control portion of the 
graphical program which is necessary or desired to execute in machine language on a programmable CPU is 
executed by the host CPU in the computer system 102, and is not executed locally by a CPU on the interface card 
114. 

20 In the embodiment of Figure 3B, the CPU 212 is not included on the interface card 1 14, i.e., the interface 

card 1 14 includes the FPGA 206 and the memory 214. In this embodiment, the memory 214 is used for storing 
FPGA state information. Figure 3B is the currently preferred embodiment of the present invention. 

Figure 4 - Conversion of Graphical Code into a Hardware Implementation 
25 Referring now to Figure 4, a flowchart diagram is shown illustrating operation of the preferred 

embodiment of the present invention. The present invention comprises a computer-implemented method for 
generating hardware implementations of graphical programs or graphical code. It is noted that various of the steps in 
the flowcharts below can occur concurrently or in different orders. 

The method below presumes that a graphical programming development system is stored in the memory of 
30 the computer system for creation of graphical programs. In the preferred embodiment, the graphical programming 
system is the LabVIEW graphical programming system available from National Instruments. In this system, the 
user creates the graphical program in a graphical program panel, referred to as a block diagram window and also 
creates a user interface in a graphical front panel. The graphical program is sometimes referred to as a virtual 
instrument (VI). The graphical program or VI will typically have a hierarchy of sub-graphical programs or sub- 
35 Vis. 

As shown, in step 302 the user first creates a graphical program, also sometimes referred to as a block 
diagram. In the preferred embodiment, the graphical program comprises a graphical data flow diagram which 
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specifies functionality of the program to be performed. This graphical data flow diagram is preferably directly 
compilable into machine language code for execution on a computer system. 

In step 304 the method operates to export at least a portion of the graphical program to a hardware 
description. Thus, after the user has created a graphical program in step 302, the user selects an option to export a 
5 portion of the graphical program to a hardware description. The hardware description is preferably a VHDL 

description, e.g., a VHDL source file, or alternatively is a high level net list description. The hardware description 
comprises a high level hardware description of function blocks, logic, inputs, and outputs which perform the 
operation indicated by the graphical program. The operation of exporting at least a portion of a the graphical 
program to a hardware description is discussed in more detail with the flowchart of Figure 6. 
10 In one embodiment, during creation of the graphical program in step 302 the user specifies portions, e.g. 

sub Vis, which are to be exported to the hardware description format for conversion into hardware implementation. 
In another embodiment, when the user selects the option to export a portion of the graphical program to the 
hardware description format, the user selects which modules or sub-VIs at that time which are to be exported to the 
hardware description. 

15 In step 306 the method operates to convert the hardware description into an FPGA -specific net list. The 

net list describes the components required to be present in the hardware as well as their interconnections. 
Conversion of the hardware description into the FPGA -specific net list is preferably performed by any of various 
types of commercially available synthesis tools, such as those available from Xilinx, Altera, etc. 

In the preferred embodiment, the converting step 306 may utilize one or more pre-compiled function 

20 blocks from a library of pre-compiled function blocks 308. Thus, for certain function blocks which are difficult to 
compile, or less efficient to compile, from a hardware description into a net list format, the hardware description 
created in step 304 includes a reference to a pre-compiled function block from the library 308. Alternatively, 
hardware implementations for all of the function blocks are included in the function library. The respective pre- 
compiled function blocks are simply inserted into the net list in place of these references in step 306. The preferred 

25 embodiment of the invention thus includes the library 308 of pre-compiled function blocks, also referred to as the 
component library, which are used in creating the net list. The preferred embodiment also includes hardware target 
specific information 3 1 0 which is used by step 306 in converting the hardware description into a net list which is 
specific to a certain type or class of FPGA. 

In step 312 the method operates to compile the net list into an FPGA program file, also referred to as a 

30 software bit stream. The FPGA program file is a file that can be readily downloaded to program an FPGA. 

After the net list has been compiled into an FPGA program file in step 312, then in step 3 14 the method 
operates to transfer the FPGA program file to the programmable hardware, e.g., the FPGA, to produce a 
programmed hardware equivalent to the graphical program. Thus, upon completion of step 314, the portion of a 
graphical program referenced in step 304 is comprised as a hardware implementation in an FPGA or other 

35 programmable hardware element. 

It is noted that various of the above steps can be combined and/or can be made to appear invisible to the 
user. For example, steps 306 and 3 12 can be combined into a single step, as can steps 304 and 306. In the 
preferred embodiment, after the user creates the graphical program in step 302, the user simply selects a hardware 
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export option and indicates the hardware target or destination, causing steps 304 - 3 14 to be automatically 
performed. 



Figure 4A - Conversion of a Graphical Program into Machine Language and Hardware Implementations 
5 Figure 4A is a more detailed flowchart diagram illustrating operation of the preferred embodiment of the 

invention, including compiling a first portion of the graphical program into machine language and converting a 
second portion of the graphical program into a hardware implementation. 

As shown in Figure 4A, after the user has created a graphical program in step 302, the user can optionally 
select a first portion to be compiled into machine code for CPU execution as is normally done. In the preferred 

10 embodiment, the user preferably selects a supervisory control and display portion of the graphical program to be 
compiled into machine code for a CPU execution. The first portion comprising supervisory control and display 
portions is compiled for execution on a CPU, such as the host CPU in the computer 102 or the CPU 212 comprised 
on the interface card 1 14. This enables the supervisory control and display portions to execute on the host CPU, 
which is optimal for these elements of the program. 

15 The user selects a second portion for conversion to hardware implementation, which is performed as 

described above in steps 304-314 of Figure 4. The portion of the graphical program which is desired for hardware 
implementation preferably comprises modules or Vis which require a fast or deterministic implementation and/or 
are desired to execute in a stand-alone hardware unit. In general, portions of the graphical program which are 
desired to have a faster or more deterministic execution are converted into the hardware implementation. In one 

20 embodiment, the entire graphical program is selected for conversion to a hardware implementation, and thus step 
322 is not performed. 

Figure 5 - Creation of a Graphical Program 

Figure 5 is a more detailed flowchart diagram of step 302 of Figures 4 and 4A, illustrating creation of a 

25 graphical program according to the preferred embodiment of the invention. As shown, in step 342 the user 

arranges on the screen a graphical program or block diagram. This includes the user placing and connecting, e.g., 
wiring, various icons or nodes on the display screen in order to configure a graphical program. More specifically, 
the user selects various function icons or other icons and places or drops the icons in a block diagram panel, and 
then connects or "wires up" the icons to assemble the graphical program. The user also preferably assembles a user 

30 interface, referred to as a front panel, comprising controls and indicators which indicate or represent input/output 
to/from the graphical program. For more information on creating a graphical program in the LabVIEW graphical 
programming system, please refer tc the LabVIEW system available from National Instruments as well as the 
above patent applications incorporated by reference. 

In response to the user arranging on the screen a graphical program, the method operates to develop and 

35 store a tree of data structures which represent the graphical program. Thus, as the user places and arranges on the 
screen function nodes, structure nodes, input/output terminals, and connections or wires, etc., the graphical 
programming system operates to develop and store a tree of data structures which represent the graphical program. 
More specifically, as the user assembles each individual node and wire, the graphical programming system operates 
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to develop and store a corresponding data structure in the tree of data structures which represents the individual 
portion of the graphical program that was assembled. Thus, steps 342 and 344 are an iterative process which are 
repetitively performed as the user creates the graphical program. 

5 Figure 6 - Exporting a Portion of the Graphical Program to a Hardware Description 

Figure 6 is a flowchart diagram of step 304 of Figures 4 and 4 A, illustrating operation when the method 
exports a portion of the graphical program into a hardware description. The tree of data structures created and 
stored in step 344 preferably comprises a hierarchical tree of data structures based on the hierarchy and 
connectivity of the graphical program. As shown, in step 362 the method traverses the tree of data structures and in 

1 0 step 364 the method operates to translate each data structure into a hardware description format. In one 
embodiment, the method first flattens the tree of data structures prior to traversing the tree in step 362, 

In the present embodiment, a number of different function icons and/or primitives can be placed in a 
diagram or graphical program for conversion into a hardware implementation. These primitives include, but are 
not limited to, function nodes, constants, global variables, control and indicator terminals, structure nodes, and sub- 

1 5 Vis, etc. Function icons or primitives can be any data type, but in the current embodiment are limited to Integer or 
Boolean data types. Also, global variables are preferably comprised on a single global panel for convenience. If a 
VI appears multiple times, then the VI is preferably re-entrant and may have state information. If a VI is not re- 
entrant, then preferably multiple copies of the VI are created in hardware if the VI has no state information, 
otherwise it would be an error, 

20 In the preferred embodiment, each node which is converted to a hardware description includes an Enable 

input, a ClearEnable signal input, a master clock signal input and an EnableOut or Done signal. The Enable 
input guarantees that the node executes at the proper time, i.e., when all of its inputs have been received. The 
Clear Enable signal input is used to reset the node if state information remembers that the node was done. Hie 
Enable_Out or Done signal is generated when the node completes and is used to enable operation of subsequent 

25 nodes which receive an output from the node. Each node which is converted to a hardware description also 
includes the data paths depicted in the graphical program. 

For While loop structures, Iteration structures, Sequence structures, and Case Structures, the respective 
structure is essentially abstracted to a control circuit or control block. The control block includes a diagram enable 
out for each sub-diagram and a diagram done input for each sub-diagram. 

30 In addition to the above signals, e.g., the Enable input, the Clear_Enable signal input, the master clock 

signal input, and the Enable Out or Done signal, all global variables have numerous additional signals, including 
CPU interface signals which are specific to the type of CPU and bus, but typically include data lines, address lines, 
clock, reset and device select signals. All Vis and sub- Vis also include CPU interface signals if they contain a 
global variable. 

35 In the preferred embodiment, when an icon is defined for a VI used solely to represent a hardware 

resource connected to the FPGA, e.g., an A/D converter, with a number of inputs and outputs, a string control is 
preferably placed on the front panel labeled VHDL. In this case, the default text of the string control is placed in 
the text file created for the VHDL of the VI. Thus, in one embodiment, a library of Vis are provided each 
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representing a physical component or resource available in or to the FPGA. As these VHDL files representing 
these Vis are used, the method of the present invention monitors their usage to ensure that each hardware resource 
is used only once in the hierarchy of Vis being exported to the FPGA. When the VHDL file is written, the contents 
of the string control are used to define the access method of that hardware resource. 

5 

The following is pseudo-code which describes the operations performed in the flowchart of Figure 6: 

GenCircuit (vi) 

send GenCircuit to top level diagram of vi 

Diagram:GenCircuit(d) 

send GenCircuit to each constant in d 
send GenCircuit to each node in d 
send GenCircuit to each signal in d 

Signal: GenCircuit(s) 

declare type of signal s 

BasicNode:GenCircuit(n) 
20 declare type of component needed for n 

declare AND-gate for enabling n (if needed) 
list connections for all node inputs 

list connections for all inputs to enabling AND-gate (if needed) 

25 Constant:GenCircuit(c) 

declare type and value of constant c 

WhileLoopNode:GenCircuit(n) 

declare while loop controller component 
30 declare AND-gate for enabling n (if needed) 

list connections for all node inputs 

list connections for all inputs to enabling AND-gate (if needed) 
declare type of each shift register component 
list connections for all inputs to all shift registers 
35 declare type of each tunnel component 

list connections for all inputs to all tunnels 

CaseSelectNode:GenCircuit (n) 

14 



10 



15 



WO 99/09498 PCT/US98/13040 
declare case select controller component 
declare AND-gate for enabling n (if needed) 
list connections for all node inputs 

list connections for all inputs to enabling AND-gate (if needed) 
5 declare type of each tunnel component 

list connections for all inputs to all tunnels 

SequenceNode:GenCircuit (n) 

declare sequence controller component 
10 declare AND-gate for enabling n (if needed) 

list connections for all node inputs 

list connections for all inputs to enabling AND-gate (if needed) 
declare type of each tunnel component 
list connections for all inputs to all tunnels 

15 

SubVINode:GenCircuit (n) 

send GenCircuit to the subVI of n 
associate inputs & outputs of subVI with those of n 
declare AND-gate for enabling n (if needed) 
20 list connections for all node inputs 

list connections for all inputs to enabling AND-gate (if needed) 

Referring to the above pseudo code listing, the method starts at the VI level (the top level) and begins 
generation of VHDL by sending a message to the top level diagram. The method in turn effectively provides a 
25 message from the diagram to each constant, each node, and each signal in the diagram. 
For signals, the method then declares the signal type. 

For basic nodes, the method declares a type of the component needed, and also declare an AND-gate with 
the proper number of inputs needed in order to enable itself. In other words, basic nodes declare an AND-gate with 
a number of inputs corresponding to the number of inputs received by the node. Here, optimization is preferably 
30 performed to minimize the number of inputs actually needed. For example, if a node has three inputs, the node 

does not necessarily need a three input AND-gate if two of those inputs are coming from a single node. As another 
example, if one input comes from node A and another input comes from node B, but node A also feeds node B, 
then the input from node A is not needed in the AND gate. Thus various types of optimization are performed to 
reduce the number of inputs to each AND gate. For the basic node, the method also lists the connections for all of 
35 its inputs as well as the connections for all inputs to the enabling AND-gate. 

For a constant, the method simply declares the type and the value of the constant. 

For a While loop, the method declares a While loop controller component. The method also declares an 
AND-gate, lists AND-gate inputs, and lists node inputs in a similar manner to the basic node described above. The 
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method then declares the type for each shift register and includes a component for the shift register, and lists all the 
connections for the shift register inputs. If any tunnels are present on the While loop, the method declares the type 
of each tunnel component and list the connections for the inputs to the tunnels. For most tunnels, the method simply 
equivalences the signals for the inside and outside, without any effect. 
5 The method proceeds in a similar manner for Case and Sequence structures. For Case and Sequence 

structures, the method declares a case select controller component or a sequence controller component, 
respectively. For both Case and Sequence structures, the method also declares an AND-gate, lists AND-gate 
inputs, and lists node inputs in a similar manner to the basic node described above. The method then declares the 
component needed for any tunnels and list the connections for the inputs to the tunnels. 
10 For a sub-VI, the method sends a message to the sub- VI and associates inputs and outputs of the sub-VI 

with those of n. The method then declares an AND-gate, lists AND-gate inputs, and lists node inputs in a similar 
manner to the basic node described above. 

Figure 7 - Exporting an Input Terminal into a Hardware Description 

1 5 Figure 7 is a flowchart diagram illustrating operation when the method exports an input terminal into the 

hardware description format. As shown, in step 402 the method determines if the data provided to the input 
terminal is input from a portion of the graphical program which will be executing on the CPU, i.e., the portion of 
the graphical program which is to be compiled into machine language for execution on the CPU, or whether the 
data is input from another portion of the graphical program that is also being transformed into a hardware 

20 implementation. 

As shown, if the data input to the input terminal is determined in step 402 to be input from a portion of the 
graphical program being compiled for execution on the CPU, in step 406 the method creates a hardware description 
of a write register with a data input and data and control outputs. The write register is operable to receive data 
transferred by the host computer, i.e., generated by the compiled portion executing on the CPU. In step 408 the 

25 data output of the write register is connected for providing data output to other elements in the graphical program 
portion. In step 408 the control output of the write register is connected to other elements in the graphical program 
portion for controlling sequencing of execution, in order to enable the hardware description to have the same or 
similar execution order as the graphical program. 

If the data is determined to not be input from a portion being compiled for execution on the CPU step in 

30 402, i.e., the data is from another node in the portion being converted into a hardware implementation, then in step 
404 the method ties the data output from the prior node into this portion of the hardware description, e.g., ties the 
data output from the prior node into the input of dependent sub-modules as well as control path logic to maintain 
the semantics of the original graphical program. 

35 Figure 8 - Exporting a Function Node into a Hardware Description 

Figure 8 is a flowchart diagram illustrating operation where the method exports a function node into the 
hardware description format. In the preferred embodiment, the term "function node" refers to any various types of 
icons or items which represent a function being performed. Thus, a function node icon represents a function being 
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performed in the graphical program. Examples of function nodes include arithmetic function nodes, e.g., add, 
subtract, multiply, and divide nodes, trigonometric and logarithmic function nodes, comparison function nodes, 
conversion function nodes, string function nodes, array and cluster function nodes, file I/O function nodes, etc. 

As shown in Figure 8, in step 422 the method determines the inputs and outputs of the function node. In 
5 step 424 the method creates a hardware description of the function block corresponding to the function node with 
the proper number of inputs and outputs as determined in step 422. Alternatively, in step 424 the method includes 
a reference in the hardware description to a pre-compiled function block from the library 308. In this case, the 
method also includes the determined number of inputs and outputs of the function node. 

In step 426 the method traverses the input dependencies of the node to determine which other nodes 

1 0 provide outputs that are provided as inputs to the function node being converted. In step 428 the method creates a 
hardware description of an N input AND gate, wherein N is the number of inputs to the node, with each of the N 
inputs connected to control outputs of nodes which provide inputs to the function node. The output of the AND 
gate is connected to a control input of the function block corresponding to the function node. 

In the data flow diagramming model of the preferred embodiment, a function node can only execute when 

15 all of its inputs have been received. The AND gate created in step 428 emulates this function by receiving all 
control outputs of nodes which provide inputs to the function node. Thus the AND gate operates to effectively 
receive all of the dependent inputs that are connected to the function node and AND them together to provide an 
output control signal which is determinative of whether the function node has received all of its inputs. The output 
of the AND -gate is connected to the control input of the function block and operates to control execution of the 

20 function block. Thus, the function block does not execute until the AND gate output provided to the control input 
of the function block provides a logic signal indicating that all dependent inputs which are input to the function 
node have been received. 

Figure 9 - Exporting an Output Terminal into a Hardware Description 

25 Figure 9 is a flowchart diagram illustrating operation where the method exports an output terminal into the 

hardware description. As shown, in step 440 the method determines if the data provided from the output terminal is 
output to a portion of the graphical program which will be executing on the CPU, i.e., the portion of the graphical 
program which is to be compiled into machine language for execution on the CPU, or whether the data is output to 
another portion of the graphical program that is also being transformed into a hardware implementation. 

30 As shown, if the data output from the output terminal is determined in step 440 to be output to a portion of 

the graphical program being compiled for execution on the CPU, then in step 442 the method creates a hardware 
description of a read register with a data input and data and control outputs. The read register is operable to receive 
data generated by logic representing a prior node in the graphical program. 

In step 444 the method connects the data output of a prior node to the data input of the read register. In 

35 step 444 the control input of the read register is also connected to control sequencing of execution, i.e., to guarantee 
that the read register receives data at the proper time. This enables the hardware description to have the same or 
similar execution order as the graphical program. 
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If the data is determined to not be output to a portion being compiled for execution on the CPU step in 
440, i.e., the data is to another node in the portion being converted into a hardware implementation, then in step 446 
the method ties the data output from the output terminal into a subsequent node in this portion of the hardware 
description, e.g., ties the data output from the output terminal into the input of subsequent sub-modules as well as 
5 control path logic to maintain the semantics of the original graphical program. 

Figure 10 - Exporting a Structure Node into a Hardware Description 

Figure 10 is a flowchart diagram illustrating operation where the method exports a structure node into the 

hardware description. In the preferred embodiment, the term "structure node" refers to a node which represents 
10 control flow of data, including iteration, looping, sequencing, and conditional branching. Examples of structure 

nodes include For/Next loops, While/Do loops, Case or Conditional structures, and Sequence structures. For more 

information on structure nodes, please see the above LabVIEW patents referenced above. 

The flowchart of Figure 10 illustrates exporting a loop structure node into a hardware description. As 

shown, in step 462 the method examines the structure node parameters, e.g., the iteration number, loop condition, 
1 5 period, phase delay, etc. As discussed above, the graphical programming system preferably allows the user to 

insert certain parameters into a structure node to facilitate exporting the structure node into a hardware description. 

Iteration and looping structure nodes have previously included an iteration number and loop condition, 

respectively. According to the preferred embodiment of the invention, these structure nodes further include period 

and phase delay parameters, which are inserted into or assigned to the structure node. These provide information 
20 on the period of execution and the phase delay of the structure node. As discussed below, the period and phase 

delay parameters, as well as the iteration number or loop condition, are used to facilitate exporting the structure 

node into a hardware description. 

In step 464, the method inserts the structure node parameters into the hardware description. In step 466 

the method inserts a reference to a pre-compiled function block corresponding to the type of structure node. In the 
25 case of a looping structure node, the method inserts a reference to a pre-compiled function block which implements 

the looping function indicated by the structure node. The method also connects controls to the diagram enclosed by 

the structure node. 

Figure 1 1 - Converting a Node into a Hardware Description 

30 Figure 1 1 is a flowchart diagram of a portion of step 306 of Figures 4 and 4A, illustrating operation where 

the method converts the hardware description for a node into a net list. Figure 1 1 illustrates operation of converting 
a hardware description of a node, wherein the hardware description comprises a reference to a function block and 
may include node parameters. It is noted that where the hardware description of a node comprises a description of 
the actual registers, gates, etc. which perform the operation of the node, then conversion of this hardware 

35 description to a net list is readily performed using any of various types of synthesis tools. 

As shown, in step 502 the method examines the function block reference and any node parameters present 
in the hardware description. In step 504, the method selects the referenced pre-compiled function block from the 
library 308, which essentially comprises a net list describing the function block. In step 506 the method then 
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configures the pre-compiled function block net list with any parameters determined in step 502. In step 508 the 
method then inserts the configured pre-compiled function block into the net list which is being assembled. 



Figure 12 - Converting a Structure Node into a Hardware Description 
5 Figure 12 is a flowchart diagram illustrating operation of the flowchart of Figure 1 1, where the method 

converts the hardware description for a structure node into a net list. Figure 12 illustrates operation of converting a 
hardware description of a structure node, wherein the hardware description comprises a reference to a structure 
node function block and includes structure node parameters. 

As shown, in step 502A the method examines the function block reference and the structure node 

1 0 parameters present in the hardware description. The structure node parameters may include parameters such as the 
iteration number, loop condition, period, phase delay, etc. In step 504A the method selects the referenced pre- 
compiled function block from the library 308, which essentially is a net list describing the structure node function 
block. In step 506A the method then configures the pre-compiled function block net list with the structure node 
parameters determined in step 502A. This involves setting the period and phase delay of execution of the structure 

15 node as well as any other parameters such as iteration number, loop condition, etc. In step 508A the method then 
inserts the configured pre-compiled function block into the net list which is being assembled. 

Figure 13 - Function Block for a Structure Node 

Figure 1 3 is a block diagram illustrating a While loop function block. As shown, the While loop function 
20 block includes enabling period and phase inputs as well as a loop control input. The While loop function block 
provides an index output which is provided to and adder. The adder operates to increment each time the index 
signals provided to monitor the number of times the While loop is executed. The While loop further outputs Clear 
and Enable Out signals to control the program within the While loop and further receives a Loop Done signal input 
which is used to indicate whether the loop has completed. 

25 

Figure 14 - Operation of Structure Node Function Block 

Figure 14 is a state diagram illustrating operation of the while loop function block shown in Figure 13. As 

shown, a diagram start operation precedes to state A. When Phase Done is true indicating that the phase has 

completed, then the state machine advances to state B. The state machine remains in state B until the Loop Enable 
30 signal is true, indicating that the loop has been enabled to begin execution. When the Loop Enable signal is 

asserted, the state machine advances from state B to state C. In state C the Clear Output signal is asserted, clearing 

the loop output prior to execution of the loop. 

The state machine then advances from state C to state D. In state D the computation is performed, and the 

Set Enable out signal is asserted. If the period is done and the loop is not yet completed, signified by the equation: 
35 Period Done and /Loop Done 

then the state machine proceeds to an error state and operation completes. Thus, the period set for execution for the 

loop was not sufficiently long to allow the loop to complete. In other words, the loop took more time to complete 

than the period set for execution of the loop. 

19 



WO 99/09498 PCTVUS98/13040 

The state machine advances from state D to state E when the Loop Done signal is asserted prior to the 
Period Done signal being asserted, indicating that the loop has completed prior to the period allotted for the loop 
execution being over. 

The state machine then advances from state E to a wait state, as shown. If the period is done and the loop 
is not re-enabled, signified by the condition: 

Period Done & /Loop Enabled 
then the state machine advances from the Wait to the Done state. If the period has completed and the loop is still 
enabled, indicating that another execution of the loop is necessary, then the state machine advances from the Wait 
state back to the C state. Thus, the state machine advances through state C, D, E, and Wait to perform looping 
operations. 

Downloading a Hardware Implementation to the Programmable Logic 

There are various possibilities or methods for downloading a hardware implementation to the 
programmable logic. In one instance, the host CPU merely downloads the configuration to the programmable logic 
as described above. This could occur by the driver at boot up time or when the user presses the run button on the 
graphical program that was created. Alternatively, the host CPU provides the hardware implementation to a non- 
volatile memory comprised on the board, and during boot up of the board this hardware implementation is loaded 
from the non-volatile memory on the board into the programmable logic. 

Thus the reconfigurable board can be designed so that the hardware diagram is written to non-volatile 
memory instead of directly to the FPGA. This allow a hardware implementation of a diagram to begin execution at 
power-on (long before the operating system has finished booting). In this case, the diagram preferably has top- 
level enablejn and abort signals which can be configured at compile time to either allow immediate execution or to 
require a supervisory program to enable hardware execution. 

Default Configuration for Hardware Simulation 

As discussed above, in the preferred embodiment the system of the present invention comprises a 
computer system which includes an add-in card. The add-in card preferably performs a data acquisition/generation 
function, e.g., is a data acquisition card. The DAQ card includes D/A and A/D converters as well as various other 
data acquisition logic, and includes a programmable logic device such as an FPGA which is operable to receive a 
hardware implementation created in response to a graphical program created on the computer system. 

In one embodiment of the invention, the programmable logic or FPGA is operable to receive a default 
configuration, whereby the default configuration operates to configure the data acquisition board with a standard 
interface for execution of the graphical program in software. Thus, for example, the host CPU may download a 
hardware implementation to the FPGA which programs the FPGA with a default configuration of a board to 
provide a desired interface for the board. This configuration would provide the host computer with direct access to 
the I/O of the board. This is useful, for example in hardware simulation, to allow the host CPU to execute the 
graphical program or diagram in software during algorithm development to determine feasibility and perform 
debugging etc. The graphical program behaves the same as it normally would in hardware, except the program 
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runs slower due to software execution. However, software debugging tools available in the graphical programming 
system are available in order to more easily debug the program. This implementation also provides a faster compile 
time thus allowing a quicker turnaround for user bug fixes. Thus, it is anticipated that the user will download a 
default configuration to the programmable logic and execute the graphical program being created in software one 
5 or more times to facilitate debugging. Once the graphical program has been constructed to a satisfactory 

performance, then the user may download the actual hardware implementation of the graphical program to the 
programmable logic as described above. 

As discussed above, there are various possibilities or methods for downloading a default configuration to 
the programmable logic. In one instance, the host CPU merely downloads the configuration to the programmable 
10 logic as described above. This could occur by the driver at boot up time or when the user presses the run button on 
the graphical program that was created. Alternatively, the host CPU provides the default configuration to a non- 
volatile memory comprised on the board, and during boot up of the board this default configuration is loaded from 
the non-volatile memory on the board into the programmable logic. 

15 Estimation of the Size and Cost of a Hardware Implementation 

In one embodiment of the invention, the graphical programming system includes a data structure which 
includes a listing of each of the elements or components comprised in the component library, as well as the 
corresponding cost of each component in terms of gates and time of execution. Thus, in this embodiment when a 
graphical program is created, the graphical programming system operates to reference the data structure to obtain 

20 the associated gate and time costs associated with each component being used from the component library in the 
graphical program being constructed. For example, the graphical programming system totals the amount of gates 
utilized with regard to each component being used in the graphical program being constructed, and then determines 
if the programmable logic or FPGA being used has sufficient capacity to implement that graphical program. Also, 
the graphical programming system can use this data structure to determine at or prior to compile time how fast the 

25 graphical program will execute in hardware, i.e., how fast the hardware implementation will execute in the FPGA. 

Alternatively, the graphical programming system receives user input regarding desired execution time and 
utilizes the execution times of each of the elements to provide feedback to the user as to whether the graphical 
program satisfies the users requirements regarding time of execution. 

In addition, in one embodiment the component library includes multiple versions of respective 

30 components. For example, the component library includes a fast multiplier that is large and a small multiplier that 
is slow. The graphical programming system can be configured to select the appropriate version of component 
based on how much of the FPGA is consumed by the rest of the diagram and based on the loop times indicated in 
the diagram, or other input from the user and/or information in the diagram. Thus, in one embodiment, the user 
inputs both the number of gates comprised in the programmable logic being used as well as the desired time of 

35 execution, and the graphical programming system automatically selects among various versions of components in 
the component library, e.g., a slower and less complex adder vs. a faster but more complex adder, in order to 
develop a hardware implementation which is suitable for the user's application. 
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Manipulation of Non-reuseable Hardware Resources 

When a user creates a graphical program which manipulates one or more hardware resources, such as one 
or more hardware resources comprised on an add-in board, e.g., a data acquisition board, in general the hardware 
device or board will have a limited number of hardware elements that are useable by the graphical program. For 
5 example, a given data acquisition board may only have one analog input channel. At least a subset of these 
hardware elements may only be used once, i.e., are not re-useable. 

In one embodiment of the invention, the non-reusable components comprised on the hardware being 
controlled appear on a palette during configuration or construction of the graphical program. These non-reusable 
components disappear as they are used by the diagram to indicate to the user that these components have been used 
10 and thus cannot be reused. In one embodiment, the user simply drags these non-reusable components from the 
palette into the graphical program. Once these components are dragged from the palette into the graphical 
program, the component disappears from the palette, and thus the user knows that the component has been used in 
the graphical program and is thus not available for reuse. 

Where two or more hardware elements are comprised on the board which can be used, a corresponding 
15 two or more components appear in the palette. In this instance, as each component is used in the graphical 
program, the corresponding picture in the palette disappears to alert the user as to the number of remaining 
hardware components which can be used. This provides a convenient mechanism for providing information to the 
user regarding the hardware components used and prevents reuse of a non-reusable component. 

In some graphical programs, it is often convenient for a single graphical program to access a single 
20 hardware element from several locations in the graphical program or diagram. This would technically violate the 
single instance or non re-useability concept discussed above, whereby a non-reusable component can be used only 
once in a graphical program. However, where the user desires to access a single non-reusable hardware element in 
several places in a single graphical program, the user preferably constructs sequencing or implements sequencing in 
the graphical program which prevents this hardware element from being used simultaneously within the same 
25 graphical program. For example, in the LabVIEW program the user constructs sequencing using a sequence 

structure. In one embodiment, references to hardware elements in the graphical program provide a "handle" to the 
hardware which is provided to the graphical program which can be used in multiple locations within the graphical 
program. This reference or "handle" to the hardware can then be used to provide simultaneous accesses to a single 
device in the graphical program. 
30 In general, there are three different ways a graphical program or diagram can be constructed to access 

unique hardware resources. In a first instance (a) a single reference to the hardware appears in the diagram as 
discussed above. In a second instance (b) multiple references to the hardware appear in the graphical program, but 
no two of these references occur simultaneously. For example, the user can figure these multiple references in 
different frames of a sequence structure. In a third instance (c) the graphical program includes multiple references 
35 to the hardware, and the way in which the graphical program is constructed indicates that these multiple references 
may be executed simultaneously. 

In the preferred embodiment, the graphical programming system preferably detects which of the above 
cases exist and performs any necessary type of configuration to accommodate these situations. In the first instance 

22 



WO 99/09498 PCT/US98/13040 

of case (a), a single reference to the hardware appears in the graphical program, and thus the graphical 
programming system is not required to perform any special processing in generating the hardware implementation. 
In the second case (b) mentioned above, the graphical program, when converting the sequence structure to a 
hardware implementation, utilizes multiplexers to multiplex the control and data inputs to the hardware in question 
5 with the same signals to guarantee that simultaneous accesses are impossible, as indicated by the sequence 

structure. In case (c) above, the graphical programming system preferably automatically detects an instance where 
multiple references in the hardware appear, wherein they may be executed simultaneously, and configures the 
hardware implementation to prevent these multiple accesses, and thus thereby preventing possible erroneous 
operation. In this instance, the graphical programming system, during the conversion process to the hardware 

10 implementation, detects the multiple references to the hardware which can be executed simultaneously, and 

instantiates one or more multiplexers and a full arbitration circuit to control the multiplexers. The multiplexers are 
provided in the hardware implementation to prevent or avoid the possibility of simultaneous execution of these 
multiple references to the non-reusable hardware. 

In cases (b) and (c), the hardware implementations use similar multiplexers. The difference between cases 

15 (b) and (c) is that in case (c) the hardware implementation includes a control circuit. In case (b) the control signals 
are the same control signals that control which frame of the sequence is executing, and in (c) the control signals 
come from an arbitration circuit. Also, in item (b), the multiplexers that configure and implement the sequence 
structure are set or defined at compile time. Alternatively, in case (c) the arbitration unit is not necessarily defined 
as far as ordering at compile time, but the order of execution is actually defined at run time. 

20 

Probe Insertion 

In one embodiment, during creation of the graphical program, a user may insert one or more probes into 
the graphical program which operate to display data on the respective wire where the probe is located during 
execution of the graphical program. When the user inserts a probe in one or more locations in the graphical 

25 program, the corresponding hardware implementation directs the use of a time stamp generation circuit. The time 
stamp generation circuit may be included inside the programmable logic or FPGA, or the time stamp generation 
circuit is configured in a separate chip or logic block included on the board which is coupled to the FPGA. This 
time stamp generation circuit allows the graphical programming system to insert probes into the hardware 
implementation of the graphical program or diagram. The time stamp generation circuit thus comprises a hardware 

30 implementation of the probe which was inserted in the software graphical program. This enable the hardware 
debugging environment to look and feel the same as it does in the graphical programming system. 

Data Path Optimization 

In one embodiment, the graphical programming system is operable to detect graphical programs or 
35 diagrams that are streaming data to/from the host computer, and the graphical programming system inserts special 
circuits in the hardware implementation to handle DMA for high speed transfers without special consideration from 
the user. These circuits include FIFOs and circuits to generate DMA requests (DRQ) or the equivalent. 
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This method enables the graphical programming system to automatically generate a DMA circuit for the 
graphical program or diagram created by the user. In the usual case, all communication to the graphical program or 
diagram from the CPU passes through global variables. According to this embodiment, the diagram would include 
an icon which looks similar to a "write global" in the sense that it is a data sink and when the icon is executed, the 
icon would assert a DMA request (DRQ)that goes back to the DMA controller and triggers a DMA transfer. The 
FIFO and DRQ generation circuitry are built inside the FPGA when the DMA icon is used. 

Occurrences 

The Lab VIEW graphical programming system includes an occurrence capability which allows a first 
function to "go to sleep" while waiting for a second function to produce a result. In this manner, the first function 
does not consume any CPU time while waiting for the second function. Three icons are provided with associated 
control software which implement the occurrence function. A Wait on Occurrence function icon is associated with 
the first function that is waiting on the result from the second function. A Set Occurrence function icon is typically 
associated with the second function icon and triggers an occurrence when the second function produces the desired 
result. A Generate Occurrence function icon is used to pass identifier values linking multiple sources and 
destinations having Set Occurrence and Wait on Occurrence function icons, respectively. 

Occurrences share some of the properties of global variables in that their implementation depends greatly 
on whether they are "written" and "read" within a single environment (all in software, all in hardware, or crossing 
the software/hardware boundary). An occurrence that is set and detected within hardware involves set and detect 
occurrence components from the library. An occurrence that is set in hardware and detected by the host CPU can 
be mapped automatically to an interrupt. The graphical programming system, e.g., Lab VIEW, would then generate 
the interrupt handling code to run on the host computer. 

Automatic Generation of the Programmatic Interface 

In one embodiment, the hardware implementation generated by the graphical programming system, can be 
configured to be controlled by other software environments or other protocols, e.g., C, C++, Java, Visual Basic, 
Visual C++, Lab Windows CVI, other types of graphical programming systems, etc. In this embodiment, the 
graphical programming system can automatically generate a description of the hardware necessary including a 
register map, interrupt map, DMA abilities, etc. to enable other software environments to control the hardware 
implementation. For example, in the preferred embodiment using the Lab VIEW Graphical Programming System 
from National Instruments Corporation, the graphical program constructed in LabVIEW is converted into a 
hardware implementation, wherein the hardware implementation also includes the above hardware information 
necessary to allow another software development environment to control or execute the hardware implementation. 

Compensating for Poor Place and Route Results 

As discussed above, the present invention preferably uses a third party tool which converts the net list 
created from the graphical program into a hardware implementation or FPGA configuration. In one embodiment, if 
this third party tool reports that the maximum clock speed is less than expected by the graphical programming 
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system, then the graphical programming system can optionally reduce the clock speed and adjust one or more 
counter values and timers to compensate for this new clock speed. This is preferably performed in cases where 
overall performance goals are still met. 

This may be necessary in in&tances, for example, where the user has configured timing within the 
5 graphical programming on the assumption of a certain clock speed, e.g., a timing loop which assume a 20 MHz 
clock and a loop constructed based on this 20 MHz clock that loops for two milliseconds. In cases where the clock 
speed is less than expected, the hardware implementation may actually work differently than expected by the user 
due to this different clock speed. In this instance, the graphical programming system can automatically reduce the 
clock speed and adjust the counter values and respective timers to compensate for this new clock speed and thus 
1 0 provide the user with the expected performance that the user expected when he/she created the graphical program. 
This embodiment utilizes a configurable oscillator on the data acquisition board. 

Figure 15 - Simple Graphical Program Example 

Figure 15 illustrates a simple example of a graphical program. In Figure 15 the graphical program 
15 includes three input terminals and one output terminal. The graphical program simply comprises a first 2-input Add 
function node which receives input from two inputs terminals, and a second 2-input Add function node which 
receives the output from the first Add function node and receives an output from the third input terminal. The 
second 2-input Add function node provides an output to output terminal as shown. 

20 Figure 16 - Hardware Result 

Figure 16 is a conceptual diagram of the resulting hardware after the graphical program example of Figure 
15 is converted into a hardware description. As shown, the hardware diagram includes three write registers 522 - 
526 corresponding to each of the three input terminals. The data outputs of the first two write registers 522 and 524 
are provided as inputs to a first two-input adder 532, which corresponds to the first adder in the block diagram of 

25 Figure 15. The hardware description also involves creating an AND gate 534 which receives control outputs from 
each of the first two write registers 522 and 524 and provides a single output to the control input of the adder 532. 
The purpose of the AND gate 534 is to prevent the adder 532 from executing until both inputs have been received. 

The Adder 532 provides a data output to a second two-input Adder 542, which corresponds to the second 
adder in the block diagram of Figure 15. The first Adder 532 also generates an enable out signal which is provided 

30 to an input of a second AND gate 536. The other input of the AND gate 536 receives an output from the third write 
register 526, corresponding to the third input terminal. The AND gate 536 provides an output to a control input of 
the second adder 542. Thus, the AND gate 536 operates to ensure that the second adder 542 does not execute until 
all inputs have been received by the adder 542. The second adder 542 provides a data output to a read register 546 
associated with the output terminal. The second adder 542 also provides an enable out signal to the read register 

35 546, which notifies the read register 546 when valid data has been provided. 

Thus, as shown, to create a hardware description for each of the input terminals, the flowchart diagram of 
Figure 6 is executed, which operates to create a hardware description of a write register 522, 524, and 526, each 
with data and control outputs. For each adder function node, the flowchart diagram of Figure 7 is executed, which 
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operates to create a hardware description of an adder 532 or 542, and farther creates an associated N input AND 
gate 534 or 536, with inputs connected to the dependent inputs of the adder function node to ensure execution at the 
proper time. Finally, the flowchart diagram of Figure 8 is executed for the output terminal of the graphical 
program, which operates to generate a hardware description of a read register with data and control inputs. 

5 

Figures 17 - 19: Example of Converting a Graphical Program into a Hardware Implementation 

Figures 17-19 comprise a more detailed example illustrating operation of the present invention. 
Figure 17 illustrates an example graphical program (a LabVIEW diagram) which is converted into an 

FPGA implementation using the present invention. As shown, the graphical program comprises a plurality of 
10 interconnected nodes comprised in a While loop. As shown, the While loop includes shift register icons, 

represented by the down and up arrows at the left and right edges, respectively, of the While loop. A 0 constant 

positioned outside of the While loop is connected to the down arrow of the shift register at the left edge of the 

While loop. 

The While loop includes a timer icon representing or signifying timing for the While loop. The timer icon 

1 5 includes inputs for period and phase. As shown, the timer icon receives a constant of 1 000 for the period and 

receives a constant of 0 for the phase. In an alternate embodiment, the While loop includes input terminals which 
are configured to receive timing information, such as period and phase. 

Figure 1 8 illustrates the LabVIEW data structures created in response to or representing the diagram or 
graphical program of Figure 17. The data structure diagram of Figure 17 comprises a hierarchy of data structures 

20 corresponding to the diagram of Figure 17. As shown, the LabVIEW data structure representation includes a top 
level diagram which includes a single signal connecting the 0 constant to the left hand shift register of the While 
loop. Thus the top level diagram includes only the constant (0) and the While loop. 

The While loop includes a sub-diagram which further includes left and right shift register terms, the 
continue flag of the While loop, a plurality of constants, a timer including period and phase inputs, global variables 

25 setpoint and gain, sub- Vis a/d read and d/a write, and various function icons, e.g., scale, add, subtract, and multiply. 
Further, each of the objects in the diagram have terminals, and signals connect between these terminals. 

Figure 19 illustrates a circuit diagram representing the hardware description which is created in response 
to the data structures of Figure 18. The circuit diagram of Figure 19 implements the graphical program of Figure 
17. As shown, the CPU interface signals are bussed to the global variables. Although not shown in Figure 19, the 

30 CPU interface signals are also provided to the sub-Vis a/d read and d/a write. 

The While loop is essentially abstracted to a control circuit which receives the period and phase, and 
includes an external enable directing the top level diagram to execute, which starts the loop. The loop then 
provides a diagram enable(diag^enab) signal to start the loop and waits for a diagram done (diag_done) signal to 
signify completion of the loop, or the period to expire. Based on the value of the Continue flag, the loop provides a 

35 subsequent diag_enab signal or determines that the loop has finished and provides a Done signal to the top level 
diagram. Although not shown in Figure 19, the loop control block also provides a diagram clear enable out 
(diag_clear_enabj)ut) signal to every node in the sub-diagram of the While loop. Thus the loop control block 
outputs a diagram enable (diag_enab) signal that is fed to all of the starting nodes in the diagram within the While 
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loop. The Done signals from these items are fed into an AND gate, whose output is provided to enable subsequent 

nodes. 

The shift register includes a data in, a data out and an enable input which clocks the data in (din) to the 
data out (dout), and a load which clocks the initial value into the shift register. 
5 The following is the VHDL description corresponding to the example of Figures 17-19, wherein the 

VHDL description was created using the present invention: 



library ieee; 

use ieee.stdJogic_1164.all; 

10 

entity exampleO is 
port( 

elk : in stdjogic; 

enable Jn : in std jogic; 
15 clr_enable out : in stdjogic; 

da_clk : in stdjogic; 

cpu_clk : in stdjogic; 

cpu_reset : in stdjogic; 

cpu iord : in stdjogic; 
20 cpu Jowt : in stdjogic; 

cpu_devsel : in stdjogic; 

cpu Joaddr : in std logic vector(3 1 downto 0); 

cpujodata : in stdJogic_vector(3! downto 0); 

ad_clk : in stdjogic; 
25 enable_out : out stdjogic 

); 

end exampleO; 

architecture Structural of exampleO is 
30 signal sCLK : stdjogic; 

signal sda_clk : stdjogic; 

signal scpu_clk : stdjogic; 

signal scpureset : stdjogic; 

signal scpu iord : stdjogic; 
35 signal scpujowt : stdjogic; 

signal scpu_devsel : stdjogic; 

signal scpu Joaddr : std_logic_vector(3 1 downto 0); 

signal supu Jodata . stdJogic_vector(3 1 downto 0); 

signal sad_clk : stdjogic; 
40 signal s 1 AC : std Jogic_vector( 1 5 downto 0); 



signal si 15 : stdjogic; — node 1 14 enable_out 

constant cE8C : stdJogic_vector(15 downto 0) := "0000000000000000"; - 0 
signal si 14 : stdjogic; - diagram done 
45 signal si 16 : stdjogic; - diagram clr_enable out 

signal s278D : stdjogic; - node 278C enable_out 
signal si 45 : stdjogic; - node 144 enable_out 
component shift 16 
port( 

50 * elk : in stdjogic; 

enable jn, load : in stdjogic; 
initval : in stdJogic_vector(15 downto 0); 
din : in stdJogic_vector(15 downto 0); 
dout : out std logic_vector(15 downto 0) 
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); 

end component; 

signal s!310 : stdJogic_vector(15 downto 0); 
signal s209C : stdJogic_vector(15 downto 0); 
signal si 344 : std_logic_vector(15 downto 0); 
signal si 628 : std_logic_vector(15 downto 0); 
signal si 270 : std_logic_vector(15 downto 0); 
signal si 684 : std_logic_vector(15 downto 0); 
signal sl9CC : std_logic_vector(15 downto 0); 
signal si 504 : stdJogic_vector(15 downto 0); 
signal sl49C : stdJogic_vector(15 downto 0); 
signal sC44 : std_logic_vector(3 1 downto 0); 
signal s974 : std Jogic_vector(3 1 downto 0); 
signal s4D8 : stdjogic; 



'00000000000000000000001 1 1 1 101000"; 



signal s2Al : stdjogic; - node 2A0 enable_out 
constant c470 : stdjogic := T; 
constant c948 : stdJogic_vector(31 downto 0) := " 



constant cC04 : stdJogic_vector(3 1 downto 0) := "00000000000000000000000000000000"; 
constant cl960 : stdJogic_vector(15 downto 0) := "1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 n ; — 1 
signal s2A0 : stdjogic; - diagram done 
signal s2A2 : stdjogic; - diagram clr_enab!e_out 
component write_reg 
port( 

elk : in stdjogic; 

enable Jn : in stdjogic; 

clr_enable_out : in stdjogic; 

cpu_clk : in stdjogic; 

cpu_reset : in std_logic; 

cpu Jord : in stdjogic; 

cpu Jowt : in stdjogic; 

cpu_devsel : in stdjogic; 

cpujoaddr : in stdJogic_vector(31 downto 0); 

cpu iodata : in std Jogic_vector(3 1 downto 0); 

decodeaddr : in std_logic__vector(3 downto 0); 

data : out stdJogic_vector(15 downto 0); 

enable_out : out stdjogic 

); 

end component; 

signal s5BA : std logic_vector(3 downto 0); 
constant c5B8 : stdJogic_vector(3 downto 0) := "00"; 
signal slA7E : stdJogic_vector(3 downto 0); 
constant cl A7C : stdJogic_vector(3 downto 0) := "10"; 
signal s641 : stdjogic; - node 640 enable_out 
signal s39D : std_logic; - node 39C enable_out 
component a_d_read 
port( 

elk : in std_logic; 

enablejn, clr_enable_out : in std_logic; 
ai_read_val : out stdJogic_vector(15 downto 0); 
ad_clk : in stdjogic; 
enable_out : out stdjogic 

); 

end component; 
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signal sl3Al : stdjogic; - node 13A0 enable_out 
component prim_Scale J3y_Power_Of_2_ 1 6 
port( 

5 elk : in stdjogic; 

enable_in, clr_enable_out : in stdjogic; 
xJ2_n : out stdJogic_vector(15 downto 0); 
x : in std_logic_vector(15 downto 0); 
n : in stdJogic_vector(15 downto 0); 
10 enable_out : ou'i stdjogic 

); 

end component; 

signal slOE9 : stdjogic; « node 10E8 enable_out 
1 5 component prim_Subtract_ 1 6 

port( 

elk : in stdjogic; 

enablejn, clr_enable_out : in stdjogic; 
x_y : out stdJogic_vector(15 downto 0); 
20 y : in stdJogic_vector(15 downto 0); 

x : in stdJogic_vector(15 downto 0); 
enable_out : out stdjogic 

); 

end component; 

25 

signal sl4Dl : stdjogic; - node 14D0 enable_out 
component prim_AddJ6 
port ( 

elk : in stdjogic; 

30 enablejn, clr_enable_out : in stdjogic; 

x_y : out stdJogic_vector(15 downto 0); 
y : in stdJogic_vector(15 downto 0); 
x : in std logic_vector(15 downto 0); 
enable_out : out stdjogic 

35 ); 

end component; 

signal si A01 : stdjogic; - node 1 A00 enable_out 
component prim_Multiply_l 6 
40 port ( 

. cik : in stdjogic; 

enablejn, clr_enable_put : in stdjogic; 
x_y : out std_logic_vector(15 downto 0); 
y : in stdJogic_vector(15 downto 0); 
45 x : in std logic_vector(15 downto 0); 

enable_out : out stdjogic 

); 

end component; 

50 signal si 725 : stdjogic; node 1724 enable_out 

component dawrite 
port( 

elk : in stdjogic; 

enablejn, clr_enable_out : in std^logic; 
55 a0_write_val : in stdJogic_vector(15 downto 0); 

da_clk : in stdjogic; 
enable_out : out stdjogic 
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); 

end component; 

component whileloopjimed 
port( 

elk : in stdjogic; 

enablejn, clr_enable_out : in stdjogic; 

diag_enable, diag_clr_enable_out : out stdjogic; 

diag_done : in stdjogic; 

period : in stdJogic_vector(15 downto 0); 

phase : in stdJogic_vector(15 downto 0); 

continue : in stdjogic; 

enable_out : out stdjogic 

); 

end component; 

begin 

sl!4<=s278D AND s!45; 

slAC<=cE8C; 

nDF8:shiftl6 

port map( 

elk => sCLK, 

load =>sl!5, 

enable_in => s2A0, 

initval=>slAC, 

din=> si 344, 

dout =>sl9CC 



s2A0<=s!725; 
s4D8 <= c470; 
s974 <= c948; 
sC44 <= cC04; 
sl684<=cl960; 

- setpoint 

n5B8: write, reg 
port map( 

elk => sCLK, 
enable in => s2Al, 
clr_enable_out => s2A2, 
enable_out => s5B9, 
cpu_clk => scpu_clk, 
cpu_reset => scpu reset, 
cpu Jord => scpu iord, 
cpu iowt => scpu Jowt, 
cpu_devsel -> scpu_devsel, 
cpu_ioaddr => scpu Joaddr, 
cpu_iodata => scpu Jodata, 
decodeaddr => s5BA, 
data=>sl49C 



s5BA <= c5B8; 
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- gain 

nlA7C: write_reg 
port map( 

elk => sCLK, 

5 enable_in => s2A 1 , 

clr_enable_out => s2A2, 
enable_out => slA7D, 
cpu_clk => scpu_clk, 
cpu_reset => scpu_reset, 

10 cpu_iord => scpu_iord, 

cpujowt => scpujowt, 
cpu_devsel => scpu_devsel, 
cpujoaddr => scpu Joaddr, 
cpu_iodata => scpujodata, 

1 5 decodeaddr => s 1 A7E, 

data => si 628 

); 

slA7E<=clA7C; 
20 n39C: a_d_read 

port map( 

elk =>sCLK, 
enablejn => s2Al, 
c!r_enable_out ^> s2A2, 
25 ai_read_val => s 1 504, 

ad_clk => sadclk, 
enable_out => s39D 

); 

30 n 1 3 AO: prim_Scale_By_Power_Of_2_l 6 

port map( 

elk => sCLK, 
enable_in => s2Al, 
clr_enable_out => s2A2, 

35 x_2_n=>sl270, 

x=>s!9CC, 
n=>s!684, 
enable_out => sl3Al 

); 

40 

sl0E8<=s39DANDs5B9; 
nl0E8: prirn_Subtract_16 
port map( 

elk => sCLK, 

45 enable_Jn=>sl0E8, 

clr_enable_out => s2A2, 

y__y=> S l3l0, 

y=>sl504, 
x =» sl49C, 

50 enable_out=>sl0E9 

); 

sl4D0<=sl3Al ANDslOE9; 

n!4D0: prim_Add_16 
55 portmap( 

elk -> sCLK, 
enabIe_in=>sl4D0, 
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clr_enable_out => s2A2, 

x_y => si 344, 

y=>s!270, 

x=>s!310, 

enable out => sl4DI 



); 



slA00<=sl4Dl AND si A7D; 
nlAOO: prim_Multiply_16 

10 portmap( 

elk => sCLK, 
enable_in => slAOO, 
clr_enable_out => s2A2, 
x_y=>s209C, 

15 y=>sl344, 

x => si 628, 
er*able_out => s 1 AO 1 

); 

20 nl724:d_a_write 

port map( 

clk=>sCLK, 
enable_in =>slA01, 
clr_enabIe_out => s2A2, 

25 aO_write_val => s209C, 

da_clk => sda_clk, 
enable_out =>s!725 

); 

30 nl44: whileloop_timed 

port map( 

cik => sCLK, 
enable_in => s 1 1 5, 
clr_enable_out => si 16, 

35 period => sC44, 

phase => s974, 
diag_enable => s2Al, 
diag_clr_enable_out => s2A2, 
diag_done => s2A0, 

40 continue => s4D8, 

enable_out => si 45 

); 

sCLK <= elk; 
45 si 15 <- enable Jn; 

si 16 <= clr_enable_out; 

si 14 <= enable_out; 

sda_clk <= da_clk; 

scpu_clk <= cpu__clk; 
50 scpu_reset <= cpujeset; 

scpu_iord <= cpu_iord; 

scpu_iowt <= cpujowt; 

scpu_devsel <= cpudevsel; 

scpu Joaddr <= cpv._ioaddr; 
55 scpu_iodata <= cpujodata; 

sad_clk <= ad_clk; 
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Component Library 

5 The preferred embodiment of the present invention includes a component library that is used to aid in 

converting various primitives or nodes in a graphical program into a hardware description, such as a VHDL source 
file. The following provides two examples of VHDL components in this component library, these being 
components for a While loop and a multiplier primitive. 



10 1. While Loop Component 

The following comprises a VHDL component referred to as whileloop.vhd that the present invention uses 
when a While loop appears on a graphical program or diagram. Whileloop.vhd shows how a While loop in a 
graphical program is mapped to a state machine in hardware. It is noted that other control structures such as a "For 
loop" are similar. Whileloop.vhd is as follows: 

15 

library ieee; 

use ieee.stdjogicj 164.aH; 

entity whileloop is 
20 port( 
elk, 

enablejn, - start loop execution 
dlr_enable_out - reset loop execution 
: in stdjogic; 

25 diag_enable, - start contained diagram execution 

diag_clr_enable_out « reset contained diagram execution 

: out stdjogic; 
diag_done, - contained diagram finished 
continue — iteration enabled 

30 : in stdjogic; 

enable_out - looping complete 
: out stdjogic 

); 

end whileloop; 

35 

architecture rtl of whileloop is 

type state J is (idle_st, — reset state 

test_st, - check for loop completion 
40 calc_st, - enable diagram execution 

end_st assert enable_out 

); " . 

signal nstate,state : statej; 
45 begin 

process(state,enabIe_in,clr_enable_out,diag_done,continue) 
begin 

diag_clr_enable_out <= '0'; 
50 diag_enable <= '0'; 

enable_out <= '0'; 
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case state is 
when idle_st => 
diag_clr_enable_out <= T; 

if enable Jn-T then 
nstate <= test_st; 
else 

nstate <= idle_st; 
end if; 

when test_st => 
diag^clr_enable_out <= T; 



if continue- V then 
15 nstate <= calcjt; 

else 

nstate <= end_st; 
end if; 

20 when calc_st => 

diag_enable <=T; 

if diag_done=T then 

nstate <= test_st; 
25 else 

nstate <= calc_st; 
end if; 

when end_st => 
30 enable_out <= T; 

nstate <= end_st; 

end case; 

35 - Because it appears at the end of the process, this test 

overrides any previous assignments to nstate 
if clr_enable_out=T then 
nstate <= idle_st; 
end if; 

40 end process; 

process(clk) 
begin 

if elk 1 event and clk=T then 
45 state <= nstate; 

end if; 
end process; 



50 



end rtl; 

2, Multiplier Primitive Component 

The following comprises a VHDL component referred to as prim_multiply_16.vhd that the present 
invention uses when a multiplier primitive appears on a graphical program or diagram. By following the path from 
enable_in to enable_put, it can be seen how the self-timed logic works - each component asserts enable_out when 
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the data output is valid. Other primitives like "add" or "less than" operate in a similar manner. 
Prim_multiply_16.vhd is as follows: 



library ieee; 
5 use ieee.std Jogic_ 1 1 64.all; 

entity prim_multiply_16 is 
port( 

elk : in stdjogic; 
10 enable Jn : in stdjogic; 

clr_enable_out : in stdjogic; 

x_y : out stdJogic_vector(15 downto 0); 

x : in stdJogic_vector(15 downto 0); 

y : in stdJogic_vector(15 downto 0); 
1 5 enable_out : out stdjogic 

); 

end prim_multiplyJ6; 

architecture -altera of prim_multiply_16 is 

20 

COMPONENT lpm_mult 
GENERIC (LPM_WIDTHA: POSITIVE; 
LPM_WIDTHB: POSITIVE; 
LPM_WIDTHS: POSITIVE; 
25 LPM_WIDTHP: POSITIVE; 

LPM_REPRESENTATION: STRING := "UNSIGNED"; 
LPM_PIPELINE: INTEGER := 0; 
LPM_TYPE: STRING :» "LJvlULT" 

); 

30 PORT (dataa: IN STD J.OGICJVECTOR(LPM_WIDTHA- 1 DOWNTO 0); 
datab: IN STD_LOGIC_VECTOR(LPM_WIDTHB-l DOWNTO 0); 
aclr:INSTDJ.OGIC:='0'; 
clock: IN STD_LOGIC := '0*; 

35 sum: IN STD_LOGIC_VECTOR(LPM_WIDTHS-l DOWNTO 0) := (OTHERS => '0'); 

result: OUT STD_LOGICJ/ECTOR(LPM_WIDTHP-l DOWNTO 0)); 
END COMPONENT; 

signal l_x,l_y : stdJogic_vector(15 downto 0); 
40 signal l_xy : stdJogic_vector(3 1 downto 0); 
signal l_enpblejn : stdjogic; 

begin 

45 — synchronize the incoming and outgoing data to guarantee 
~ a registered path on data through the multiplier 

— register enable_out so it won f t assert before data is 

- available. 
process(clk) 

50 begin 

if elk'event and clk=T then 
if clr_enable_out=T then 
enable_out <= '0'; 
l_enablejn <= '0'; 
55 else 

enable_out <= l_enablejn; 

35 
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]_enable_in <= enablejn; 
end if; 

l_x <= x; 
5 l_y<=y;. 

x_y <= l_xy(15 downto 0); 

end if; 
end process; 

gainx: lpmjnult 
GENERIC map( 
LPM_WIDTHA=> 16, 
LPM_WIDTHB ==> 16, 
LPMJVIDTHS => 1, 
LPMJVIDTHP => 32, 

LPM_REPRESENTATION => "UNSIGNED", 
LPMJPIPELINE => 0 
) 

PORT map( 
dataa => l_x, 
datab -> I_y, 

result => l_xy 

25 ); 

end altera; 
Figures 20-21 

30 Figures 20 and 21 illustrate the graphical source code of a graphical program or VI called example 1 .vi. 

The following comprises a VHDL hardware description created from the graphical program example l.vi 
shown in Figures 20 and 21, wherein the VHDL hardware description set out below was directly generated from the 
LabVIEW program example l.vi using the present invention. 



35 library ieee; 

use ieee.stdJogic_1164.all; 

entity example 1 is 
port( 

40 address : out std_logic_vector(l downto 0); — address to DAC 

wr : out std_logic; - control to DAC 

cs : out stdjogic; - control to DAC 

ldac : out stdjogic; - control to DAC 

dac_data : out std Jogic_vector(7 downto 0); - data to DAC 
45 cclk : in stdjogic; 

CAout : in stdJogic_vector(l 1 downto 0); 

CDin : out stdJogic_vector(CFG JDRWIDTH downto 0); 

CDout : in stdJogic_vector(CFG JDRWIDTH downto 0); 

dreset : in stdjogic; 
50 ioupdate : in stdjogic; 

rc : out stdjogic; - convert signal to ADC 

stat : in stdjogic; - convert "done" signal from ADC 

adc_data : in stdJogic_vector(l 1 downto 0); data from ADC 

osc : in stdjogic 

36 
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); 

end example 1; 

architecture Structural of example 1 is 
5 signal sCLK : stdjogic; 

signal saddress : stdJogic_vector(l downto 0); 
signal swr : stdjogic; 
signal scs : stdjogic; 
signal sldac : stdjogic; 
10 signal sdac_data : stdJogic_vector(7 downto 0); 

signal scclk : stdjogic; 

signal sCAout : stdJogic_vector(l 1 downto 0); 
signal sCDin : stdjogic vector(CFG_DR WIDTH downto 0); 
signal sCDout : stdlogic_vector(CFGJ)R WIDTH downto 0); 
15 signal sdreset : stdjogic; 

signal sioupdate : stdjogic; 
signal src : stdjogic; 
signal sstat : stdjogic; 

signal sadc_data : stdJogic_vector(l 1 downto 0); 
20 signal si 98 : stdJogic_vector(15 downto 0); 

signal si 01 : stdjogic, - node 10C enable_out 
signal si 00 : stdjogic; - node 100 enable Jn 

constant cB8C : stdJogic_vector(15 downto 0) := "0000000000000000"; ~ 0 
25 signal si 00 : stdjogic; ~ diagram done 

signal si 02 : stdjogic; — diagram clr_enable_out 

signal si 305 : stdjogic; - node 1304 enable_out 

signal si 31 : stdjogic; — node 130 enable_out 

component shift 16 
30 port ( 

elk : in stdjogic; 
enablejn, load : in stdjogic; 
initval : in stdJogic_vector(15 downto 0); 
din : in stdJogic_yector(15 downto 0); 
35 * dout : out stdJogic_vector(15 downto 0) 

); 

end component; 

signal si 1A0 : stdJogic_vector(15 downto 0); 
40 signal si 984 : stdJogic_vector(15 downto 0); 

signal s3F60 : stdJogic_vector(7 downto 0); 

signal s3EE0 : stdJogic_vector(15 downto 0); 

signal s3D0C : stdJogic_vector(15 downto 0); 

signal sA98 : stdJogic_vector(15 downto 0); 
45 signal s880 : stdjogic_vector(15 downto 0); 

signal s4C0 : stdjogic; 

signal s28D : stdjogic; ~ node 28C enable_out 
constant c458 : stdjogic := T; 
50 constant c854 : stdJogic_vector(15 downto 0) := "0000001 1 1 1 101000"; - 1000 

constant cA58 : stdJogic_vectoi<15 downto 0) := "0000000000000000"; 0 
signal s28E : stdjogic; — diagram clr_enable_out 
component write_reg8 
port( 

55 elk : in stdjogic; 

enablejn : in stdjogic; 
clr_enable_put : in stdjogic; 
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cclk : in stdjogic; 

CAout : in stdJogic_vector(l 1 downto 0); 

CDin : out std_logic_vector(CFG_DRWIDTH downto 0); 

CDout : in stdJogic_vector(CFG_DR WIDTH downto 0); 

dreset : in stdjogic; 

ioupdate : in stdjogic; 

decode : in stdjogic; 

data : out stdJogic_vector(7 downto 0); 

enable_out : out stdjogic 

); 

end component; 

signal s4Cl A : stdjogic; - decode_sig 
signal s4C19 : stdjogic; — node 4C18 enable out 
signal s561 : stdjogic; - node 560 enable_out 
signal s389 : stdjogic; - node 388 enable_out 
component ADC_read 
port( 

elk : in stdjogic; 

enablejn, clr_enable_put : in stdjogic; 

ai_read_val : out stdJogic_vector(15 downto 0); 

rc : out stdjogic; — convert signal to ADC 

stat : in stdjogic; - convert "done" signal from ADC 

adc_data : in std_logic_vector(l 1 downto 0); -- data from ADC 

enable__out : out stdjogic 

); 

end component; 

signal sl4CD : stdjogic; - node 14CC enable_out 
signal sl4CC : stdjogic; — node 14CC enablejn 

signal si AID : stdjogic; - node 1A1C enable_out 
signal si A IE : stdjogic; - diagram clr_enable_out 
signal s3FC0 : std Jogic_vector( 1 5 downto 0); 
signal s24F0 : std Jogic_vector( 1 5 downto 0); 
signal s22F8 : stdJogic_vector(15 downto 0); 
signal s237C : stdJogic_vector( 15 downto 0); 
signal s2524 : stdJogic_vector(15 downto 0); 
signal s241C : stdjogic; 
signal s246C : stdjogic; 
signal s24A0 : stdjogic; 

signal si BD5 : stdjogic; - node 1BD4 enable_out 

constant cl A6C : stdJogic_vector(l 5 downto 0) := "00000000100101 10"; - 150 
constant clC04 : stdJogic_vector(15 downto 0) := "00000000001 10010"; 50 
signal slBD6 : stdjogic; - diagram clr_enable_out 
component write_regl6 
port( 

elk : in std_logic; 
enablejn : in stdjogic; 
clr_enable_out : in stdjogic; 
cclk : in stdjogic; 

CAout : in stdJogic_vector(l 1 downto 0); 

CDin : out std_logic_vector(CFG_DRWIDTH downto 0); 

CDout : in std_logic__vector(CFG_DRWIDTH downto 0); 

dreset : in stdjogic; 

ioupdate : in stdjogic; 
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decode : in stdjogic; 

data : out std_logic_vector(15 downto 0); 

enable_out : out stdjogic 

. ); 

5 end component; 

signal s4322 : stdjogic; - decode_sig 
signal s4321 : stdjogic; - node 4320 enable out 
signal s446E : stdjogic; - decode_sig 
1 0 signal s446D : stdjogic; - node 446C enable out 

signal s41El : stdjogic; ~ node 41 E0 enable_out 
signal s41E0 : stdjogic; - node 41 E0 einablejn 
component prim_Less J3r_Equal J 6 
port( 

15 elk : in stdjogic; 

enablejn, clr_enable_out : in stdjogic; 

x_LE_y : out stdjogic; 

y : in stdJogic_vector(15 downto 0); 

x : in stdJogic_vector(15 downto 0); 
20 enable_out : out stdjogic 

); 

end component; 

signal slD7D : stdjogic; — node 1D7G enable_out 
25 signal slD7C : stdjogic; - node 1D7C enablejn 

component prim_Less_16 
' port( 

elk : in stdjogic; 

enablejn, clr_enable_out : in stdjogic; 
30 . xJLT_y : out stdjogic; 

y : in std Jogic_vector( 1 5 downto 0); 
x : in stdJogic_vector(15 downto 0); 
enable_out : out stdjogic 

); 

35 end component; 

signal s225D : stdjogic; - node 225C enable_out 
signal s225C : stdjogic; - node 225C enablejn 
component prim_Or 
40 port ( 

elk : in stdjogic; 

enablejn, clr_enable_out : in stdjogic; 
x _ or _y : out stdjogic; 
y : in stdjogic; 

45 x : in stdjogic; 

enable_out : out stdjogic 

); 

end component; 

50 signal s2089 : stdjogic; - node 2088 enable_out 

signal s2088 : stdjogic; - node 2088 enablejn 
component prim_Select J 6 
port( 

elk : in stdjogic; 

55 enablejn, clr_enable_out : in stdjogic; 

sj_f : out std_logic_vector(15 downto 0); 
f : in stdJogic_vector(15 downto 0); 
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s : in stdjogic; 

t : in std_logic_vector(15 downto 0); 
enable_out : out stdjogic 

); 

end component; 

signal s2C08 : stdJogic_vector(15 downto 0); 
signal s2728 : std Jogic_vector( 1 5 downto 0); 

signal s2585 : stdjogic; - node 2584 enable_out 
signal s2586 : stdjogic; - diagram clr_enable_out 
signal sFCA : stdjogic; - decode_sig 
signal sFC9 : stdjogic; - node FC8 enable out 
signal s25B5 : stdjogic; « node 25B4 enable_out 
signal s25B4 : stdjogic; - node 25B4 enablejn 
component prim JVIultiply J 6 
port( 

elk : in stdjogic; 

enablejn, clr_enable_put : in stdjogic; 
xTIMESy : out stdJogic_vector(15 downto 0); 
y : in stdJogic_vector(15 downto 0); 
x : in stdJogic_vector(15 downto 0); 
enable_out : out stdjogic 

); 

end component; 

signal s3964 : stdJogic_vector(15 downto 0); 
signal s3A58 : stdJogic_vector(15 downto 0); 
signal s3AA8 : stdjogic_veotor(15 downto 0); 
signal s3AF8 : stdJogic_vector(15 downto 0); 
signal s3B48 : stdlogic_vector(15 downto 0); 
signal s3B98 : std Jogic_vector( 1 5 downto 0); 
signal s3BE8 : stdJogic_vector(15 downto 0); 
signal s3C38 : stdJogic_vector(15 downto 0); 
signal s3C88 : stdJogic_vector(15 downto 0); 
signal s3CD8 : stdJogic_vector(15 downto 0); 

signal s2881 : stdjogic; « node 2880 enable_out 
constant c28D0 : stdJogic_vector(15 downto 0) := "0000000000000100" 
constant c2A68 ; stdJogic_vector(15 downto 0) := "0000000000000001" 
constant c32B4 : stdJogic_vector(15 downto 0) := "0000000000001001" 
constant c2DA8 : stdJogic_vector(15 downto 0) := "0000000000010000' 
signal s2882 : stdjogic; - diagram clr_enable_out 
signal s2F35 : stdjogic; - node 2F34 enable__out 
signal s3245 : std jogic; - node 3244 enableout 
signal s30BD : stdjogic; — node 30BC enable_out 
signal s33C5 : stdjogic; — node 33C4 enable_out 
signal s33C4 : stdjogic; — node 33C4 enable_in 
component prim_AddJ6 
port( 

elk : in stdjogic; 

enablejn, clr_enable_out : in stdjogic; 
xPLUSy : out stdJogic_vector(15 downto 0); 
y : in stdJogic_vector(15 downto 0); 
x : in stdJogic_vector(15 downto 0); 
enable_out : out stdjogic 



40 



WO 99/09498 PCT/US98/13040 
end component; 

signal s3581 : stdjogic; — node 3580 enable_out 
signal s3580 : stdjogic; - node 3580 enablejn 
5 signal s3709 : stdjogic; - node 3708 enable_out 

signal s3708 : stdjogic; - node 3708 enable Jn 
component prin\_Quotient Jlemainder J 6 
port( 

elk : in stdjogic; 

10 enable Jn, clr_enable_out : in stdjogic; 

floor_xDIVBYy : out stdJogic_vector(15 downto 0); 

xMINUSyTIMESfloor_xDIVBYy : out stdJogic_vector(15 downto 0); 

y : in std_logic_vector(15 downto 0); 

x : in stdJogic_vector(15 downto 0); 
1 5 enable_out : out stdjogic 

); 

end component; 

signal sF35 : stdjogic; - node F34 enable_out 
20 component DAC_write 

port( 

elk : in stdjogic; 

enable Jn, clr_enable_out : in stdjogic; 

ao data : in stdJogic_vector(15 downto 0); 
25 address : out stdJogic_vector(l downto 0); - address to DAC 

wr : out stdjogic; control to DAC 

cs : out stdjogic; ~ control to DAC 

Idac : out stdjogic; ~ control to DAC 

dac_data : out std Jogic_vector(7 downto 0); ~ data to DAC 
30 enable_out : out stdjogic 

); 

end component; 

component whileloopjimed 
35 port ( 

elk : in std logic; 

enablejn, clr_enable_out : in stdjogic; 
diag_enable, diag_clr_enable_out : out stdjogic; 
diag_done : in stdjogic; 
40 period : in stdJogic_vector(15 downto 0); 

phase : in stdJogic_vector(15 downto 0); 
continue : in stdjogic; 
enable_out : out stdjogic 

); 

45 end component; 

begin 

slOO <= sl305 AND s 1 3 1 ; 
50 sl98<=cB8C; 

n22C4: shiftl6 

port map( 

clk=>sCLK, 
load=>sl01, 
55 enablejn => sF35, 

initval=>sl98, 
din =>sl984, 
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dout => s3D0C 

); 

n510:shiftl6 

port map( 

elk => sCLK, 
load=>sl01, 
enablejn => sF35, 
initval=>sl98, 
din => s3D0C, 
dout =>sllA0 



s4C0 <= c458; 
s880 <= c854; 
sA98 <= cA58; 

— function 
n4C18: write_reg8 
port map( 

elk => sCLK, 

enable_in => s28D, 

clr _enable_out => s28E, 

enable_out => s4C19, 

eelk => scclk, 

CAout => sCAout, 

CDin => sCDin, 

CDout => sCDout, 

dreset => sdreset, 

ioupdate => sioupdate, 

decode => s4Cl A, 

data=> S3F60 

); 

S4C1A <= T when CAout="0000000 10000" else '0';. 
n388: ADC_read 
port map( 

elk => sCLK, 

enable_in => s28D, * 

clr_enable_out => s28E, 

ai_read_val => si 984, 

rc => sre, 

stat => sstat, 

adc_data => sadc_data, 

enable_out => s389 

); 

sl4CC <= s4C19 AND s389 AND s28D; 

s3EE0 <= si 984 when s3F60(3 downto 0)="000" else 

s22F8 when s3F60(3 downto 0)="001" else 
s2728 when s3F60(3 downto 0)="010" else 
S3964; 



S2524 <=clA6C; 
S237C <=clC04; 
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- hi limit 

n4320: write_regl6 
port map( 

5 elk => sCLK, 

enable_jn => slBD5, 
clr_enable out => slBD6, 
enable_out => s4321, 
eelk => scclk, 

10 CAout => sC Aout, 

CDin => sCDin, 
CDout => sCDout, 
dreset => sdreset, 
ioupdate => sioupdate, 

15 decode => s4322, 

data => s3FC0 

); 

S4322 <= T when CAout="000000001000" else V; 

20 

— lo limit 

n446C: write_reg!6 
port map( 

elk => sCLK, 

25 enable_in=>slBD5, 

clr_enable_out => slBD6, 
enable_out => s446D, 
eelk => scclk, 
CAout => sCAout, 

30 CDin=>sCDin, 

CDout => sCDout, 
dreset => sdreset, 
ioupdate => sioupdate, 
decode => s446E, 

35 data => s24F0 

); 

s446E <=T when CAout= M 000000001 100" else '0'; 
s4 1 E0 <= s 1 BD5 AND s432 1 ; 
40 n4 1 E0: prim_Less_Or_Equal_ 1 6 

port map( 

elk => sCLK, 
enable_Jn => s41E0, 
clr_enable_out => s 1 BD6, 
45 x_LE_y => s246C, 

y=>s!984, 
x => S3FC0, 
enable_out => s41El 

); 

50 

S1D7C <= s446D AND slBD5; 
nlD7C: prim_Less_16 
port map( 

elk =>sCLK, 

55 enable_in=>slD7C, 

clr_enable_put => slBD6, 
x_LT_y => s24A0, 
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y => s24F0, 
x=>sl984, 
enable out=> S1D7D 



); 



s225C <= S1D7D AND s41El; 
n225C: prim_Or 
port map( 

elk =» sCLK, 

10 enable _in => s225C, 

clr_enable_out => slBD6, 
x_or_y => s241C, 
y => s24A0, 
x => S246C, 

1 5 enable_out => s225D 

); 

s2088 <= slBD5 AND s225D; 
n2088: prim_Select_16 

20 port map( 

clk->$CLK, 
enable_in => s2088, 
clr_enable_put => slBD6, 
sjj => s22F8, 

25 f => s237C, 

s=>s241C, 
t=>s2524, 
enable_out => s2089 

); 

30 



- gain 

nFC8: write_regl6 

35 portmap( 

clk=>sCLK, 
enablejn ^=> s2585, 
clr_enable_put => s2586, 
enab!e_out => sFC9, 

40 eelk => scclk, 

CAout => sCAout, 
CDin => sCDin, 
CDout => sCDout, 
dreset => sdreset, 

45 ioupdate => sioupdate, 

decode => sFCA, 
data=>s2C08 

); 

50 sFCA <= T when CAout="000000000 1 00" else '0'; 

s25B4 <= sFC9 AND s2585; 
n25B4: primjVlultiply_16 
port map( 

clk=>sCLK, 

55 enable_in => s25B4, 

clr_enable_out => s2586, 
xTIMESy => s2728, 
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y => s2C08, 
x=>sl984, 
enable out=>s25B5 



); 



S3CD8 <= c28D0; 
S3C88 <= C2A68; 
S3C38 <= C32B4; 
10 s3AA8 <= C2DA8; 

n2F34: prim_Multiply_16 
port map( 

elk => sCLK, 
enable jn => s2881, 
1 5 clr_enable_out => s2882, 

xTIMESy => s3BE8, 
y => s3CD8, 
x => s3D0C, 
enable_out=>s2F35 

20 ); 

n3244: prim_Multiply_16 
port map( 

elk => sCLK, 

25 enable_in=>s2881, 

clr_enable_out => s2882, 
xTIMESy => s3B48, 
y=>s3C38, 
x=>sl984, 

30 enable_out => s3245 

); 

n30BC: prim_MultiplyJ6 
port map( 

35 elk => sCLK, 

enable_in => s2881, 
clr_enable_out => s2882, 
xTIMESy =>s3B98, 
y => s3C88, 

40 x=>sllA0, 

enable_out => s30BD 

); 

s33C4 <= s30BD AND s2F35; 

45 n33C4: prim_AddJ6 

port map( 

elk => sCLK, 
enable_in => s33C4, 
clr_enable_out => s2882, 

50 xPLUSy=>s3AF8, 

y => s3B98, 
x => s3BE8, 
enable_out => s33C5 

); 

55 

s3580 <= s3245 AND s33C5; 
n3580: prim_Add_16 
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10 



port map( 

clk=>sCLK, 
enable_in => s3580, 
clr_enable_out => s2882, 
xPLUSy => s3A58, 
y => s3B48, 
x => s3AF8, 
enable^out => s3581 

); 



s3708 <= s2881 AND s3581; 
n3708: prim_Quotient_RemainderJ6 
port map( 

elk => sCLK, 

15 enablejn => s3708, 

clr_enable_out => s2882, 
floorjcDIVBYy => s3964, 
xMFNUSyTIMESfloorjcDIVBYy => OPEN, 
y => s3AA8, 

20 x "=> s3A58, 

enable_put=> s3709 

); 

si AID <= S14CC when s3F60(3 downto 0)="000" else '0'; 
25 slAlE<=s28E; 

slBD5 <= S14CC when s3F60(3 downto 0)= M 001" else '0'; 
slBD6<=s28E; 

s2585 <= sl4CC when s3F60(3 downto OK010" else '0'; 
s2586<=s28E; 

30 s2881 <= sl4CC when s3F60(3 downto 0)="01 1" else '0'; 

s2882 <= s28E; 

sl4CD <= si AID when s3F60(3 downto 0)= n 000 M else 

S2089 when s3F60(3 downto 0)="001 " else 
S25B5 when s3F60(3 downto 0>="0 1 0" else 
35 S3709; 
nF34: DAC_write 
port map( 

clk=>sCLK, 
enable Jn => si 4CD, 
40 clr_enable_out => s28E, 

ao_data=>s3EE0, 
address => saddress, 
wr => swr, 
cs => scs, 

45 ldac => sldac, 

dac_data => sdac_data, 
enable_out=> sF35 

); 

50 nl30: whileloop^timed 

port map( 

clk=>sCLK, 

enable_in=>sl01, 

clr_enable_out => si 02, 
55 period => sA98, 

phase => s880, 

diag_enable => s28D, 



46 



WO 99/09498 



PCT/US98/13040 



diag_clr_enable_out => s28E, 



diag_done => sF35, 
continue => s4C0, 
enable out => si 31 



5 



); 



20 



15 



10 



sCLK <= osc; 
sO<=T; 
sO <= dreset; 
address <= saddress; 
wr <= swr; 
cs <= scs; 
ldac <= sldac; 
dac_data <= sdac_data; 
scclk <= cclk; 
sCAout <= CAout; 
CDin <= sCDin; 
sCDout <= CDout; 
sdreset <= dreset; 
sioupdate <= ioupdate; 
rc <= src; 
sstat <= stat; 
sadc_data <= adc_data; 



25 end Structural; 

Although the system and method of the present invention has been described in connection with the 
preferred embodiment, it is not intended to be limited to the specific form set forth herein, but on the contrary, it is 
30 intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit 
and scope of the invention as defined by the appended claims. 
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Claims 

1 . A computer-implemented method for generating a hardware implementation of graphical code, 
the method comprising: 

creating a graphical program; 

exporting at least a portion of the graphical program into a hardware description, wherein the hardware 
description describes a hardware implementation of the at least a portion of the graphical program; 

configuring a programmable hardware element utilizing the hardware description to produce a configured 
hardware element, wherein the configured hardware element implements a hardware implementation of the at least 
a portion of the graphical program. 

2. The method of claim 1 , further comprising: 
converting the hardware description into a net list; 

wherein said configuring the programmable hardware element utilizes the net list. 

3. The method of claim 2, further comprising: 
compiling the net list format into a hardware program file; and 

wherein said configuring the programmable hardware element includes downloading the hardware 
program file to the programmable hardware element to configure the programmable hardware element. 

4. The method of claim 2, wherein said converting the hardware description into a net list includes: 
utilizing at least one function block from a library of pre-compiled function blocks; and 

utilizing hardware target specific information. 

5. The method of claim 1, wherein said creating the graphical program includes: 
arranging on the screen a plurality of nodes comprising the graphical program; 

creating and storing a tree of data structures which represent the graphical program in response to said 
arranging. 

6. The method of claim 5, wherein said exporting the at least a portion of the graphical program into 
the hardware description comprises: 

traversing the tree of data structures; 

converting each data structure in the tree of data structures into a hardware description format in response 
to said traversing. 

7. The method of claim 1 , wherein the graphical program includes a plurality of nodes; 
wherein said exporting at least a portion of the graphical program into a hardware description comprises 

converting each of said nodes into a hardware description format 
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8. The method of claim 7, wherein each of said nodes is converted into a hardware description 
format including an enable input, a clock signal input, and an enable output; 

wherein, for a respective node, said enable input receives an enable signal generated from enable out 
signals from one or more nodes which provide inputs to the respective node. 

5 

9. The method of claim 7, wherein the graphical program includes an input terminal; 
wherein, for said input terminal, said converting comprises: 

determining if data input to the input terminal is from a supervisory portion executing on the 

computer system; 

10 creating a hardware description of a write register, wherein the write register includes one or 

more data outputs and at least control output 

10. The method of claim 7, wherein the graphical program includes a function node; 
wherein, for said function node, said converting comprises: 

determining inputs and outputs to/from the function node; 

creating a hardware description of logic which performs the function indicated by the function 

node; 

traversing input dependencies of the node; 

creating a hardware description of an AND gate, including listing connections of said input 
dependencies of the node to said AND gate. 

1 1 The method of claim 7, wherein the graphical program includes a structure node; 
wherein, for said structure node, said converting comprises: 

determining inputs and outputs to/from the structure node; 
25 creating a hardware description of a control block which performs the control function indicated 

by the structure node; 

traversing input dependencies of the node; 

creating a hardware description of an AND gate, including listing connections of said input 
dependencies of the node to said AND gate. 

30 

12. The method of claim 7, wherein the graphical program includes a function node; 
wherein, for said function node, said converting comprises: 

determining inputs and outputs to/from the function node; 

accessing a hardware description of logic which performs the function indicated by the function 
35 node from a library of function node hardware descriptions; 

traversing input dependencies of the node; 

creating a hardware description of an AND gate, including listing connections of said input 
dependencies of the node to said AND gate. 

49 
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13. The method of claim 7, wherein the graphical program includes a structure node; 
wherein, for said structure node, said converting comprises: 

determining inputs and outputs to/from the structure node; 

accessing a hardware description of a control block which performs the control function indicated 
5 by the structure node from a library of hardware descriptions; 

traversing input dependencies of the node; 

creating a hardware description of an AND gate, including listing connections of said input 
dependencies of the node to said AND gate. 

10 14. The method of claim 7, wherein the graphical program includes an output terminal; 

wherein, for said output terminal, said converting comprises: 

determining if data output from the output terminal is to a supervisory portion executing on the 

computer system; 

creating a hardware description of a read register, wherein the read register includes one or more 
1 5 data inputs and at least control input. 

1 5. The method of claim 7, wherein the graphical program comprises a data flow diagram. 

16. The method of claim 1, wherein the programmable hardware element comprises a field 
20 programmable gate array (FPGA). 

1 7. The method of claim 1 , wherein a first portion of the graphical program is converted into a 
hardware description; 

the method further comprising: 
25 compiling a second portion of the graphical program into machine code for execution by a CPU. 

1 8. - The method of claim 17, further comprising: 

executing the machine code to perform functionality indicated by the second portion of the graphical 
program; 

30 the configured hardware element performing functionality indicated by the first portion of the graphical 

program; 

wherein said executing the machine code and the configured hardware element performing functionality 
operate to perform functionality indicated by the graphical program. 

35 19. The method of claim 1 , wherein the method operates in a system comprising a computer system 

and a device coupled to or comprised in the computer system, wherein the programmable hardware element is 
comprised on the device, wherein the device performs data acquisition / generation functions. 
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20. The method of claim 19, wherein the device includes a non- volatile memory coupled to the 
programmable hardware element, the method further comprising: 

storing the hardware description into the non-volatile memory; 

wherein said configuring the programmable hardware element comprises transferring the hardware 
description from the non-volatile memory to the programmable hardware element to produce the configured 
hardware element. 

21 . A system which generates a hardware implementation of graphical code, the system comprising: 
a computer system comprising a CPU and memory, wherein the memory stores a graphical program, 

wherein the memory also stores a software program which is executable to export at least a portion of the graphical 
program into a hardware description, wherein the hardware description describes a hardware implementation of the 
at least a portion of the graphical program; 

a device coupled to the computer system, wherein the device includes a programmable hardware element; 

wherein the computer system is operable to configure the programmable hardware element utilizing the 
hardware description to produce a configured hardware element, wherein the configured hardware element 
implements a hardware implementation of the at least a portion of the graphical program. 

22. The system of claim 21, wherein the software program stored in the memory of the computer 
system is further operable to convert the hardware description into a net list; 

wherein the computer system is operable to configure the programmable hardware element utilizing the 

net list. 

23. The system of claim 21, wherein 'die software program stored in the memory of the computer 
system is further operable to compile the net list format into a hardware program file; and 

wherein the computer system is operable to download the hardware program file to the programmable 
hardware element to configure the programmable hardware element. 

24. The system of claim 21 , wherein the programmable hardware element comprises a field 
programmable gate array (FPGA). 

25. The system of claim 21, wherein the computer system includes a bus and also includes one or 
more expansion slots coupled to the bus adapted for receiving expansion cards 

wherein the device comprises an expansion card inserted into an expansion slot of the bus. 

26. The system of claim 2 1 , wherein the memory of the computer system stores a graphical 
programming system for creation of the graphical program; 

wherein the graphical programming system is executable to arrange on the screen a plurality of nodes 
comprising the graphical program in response to user input; 
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wherein the graphical programming system is further executable to create and store a tree of data 

structures which represent the graphical program in response to said arranging; 

wherein the software program is executable to traverse the tree of data structures and convert each data 

structure in the tree of data structures into a hardware description format in response to said traversing. 

27. The system of claim 2 1 , wherein a first portion of the graphical program is converted into a 
hardware description; 

wherein the computer system is operable to compile a second portion of the graphical program into 
machine code for execution by the CPU. 

28. The system of claim 27, 

wherein the configured hardware element is operable to perform functionality indicated by the first portion 
of the graphical program; 

wherein the computer system is operable to execute the machine code to perform functionality indicated 
by the second portion of the graphical program; 

wherein said executing the machine code and the configured hardware element performing functionality 
operate to perform functionality indicated by the graphical program. 

29. The system of claim 21, wherein the device performs data acquisition / generation functions. 

30. The system of claim 21, wherein the device includes a non-volatile memory coupled to the 
programmable hardware element; 

wherein the non-volatile memory is operable to store the hardware description; 
wherein the non-volatile memory is operable to transfer the hardware description to the programmable hardware 
element to produce the configured hardware element. 



52 



WO 99/09498 



1/25 



PCT/US98/13040 




WO 99/09498 



PCT/US98/13040 



2/25 



s 




WO 99/09498 



3/25 



PCT/US98/13040 




WO 99/09498 



4/25 



PCT/US98/13040 



ZOZJopauuoooi 



o 

CO 



Oil 



o 



CO 

° 
CNj| 

CO 

CD 

"co 
o 
o 



CD 




Volatil 




emo 


O 









CD CN 



O) o 

8 



CO 

O 

Li. 



3. CM 



O 

0> CD 

JEoll 

CO 

CD 



col 

C\]| 
CO 

m 

CO 
CO 

Q 



o 
o 



WO 99/09498 



5/25 



PCT/US98/13040 



ZQZ JOJ09UUOQ 01 



o 

CO 



o 
cnjI 



o 



O 



D> O ^> 

CO < 

C U> 7r\ CD 

o a> o 



CO 

o 

CM 
CO 

CD 

To 
o 
o 



8 














CDI 










CNJI 


CO 








m 





CO 

c^i 

CO 

CO 

16 

Q 

8 

"c 
o 
O 



< 

CO 

O 



WO 99/09498 



6/25 



PCT/US98/13040 




WO 99/09498 



PCT/US98/13040 



7/25 



Library of pre- 
compiled function 
blocks 
308 



Create graphical 
program (block 
diagram) 
302 



Export at least a 
portion of the graphical 
program to a hardware 
description 
304 



Convert the hardware 

description to an 
FPGA-specific Net-List 
306 



Compile the net list 
into an FPGA program 
file 
312 



Transfer FPGA 
program file to 
programmable 
hardware (FPGA) to 
produce programmed 
hardware equivalent to 
graphical program 
314 



Hardware target 
specific information 
310 



FIG. 4 



WO 99/09498 



PCT/US98/13040 



8/25 



Create graphical 
program (block 
diagram) 
302 



Compile supervisory 
control and display 
portion of the graphical 
program into machine 
code for CPU 
execution 
322 



Library of pre-compiled 
function blocks 
308 



Export at least a 
portion of the graphical 
program to a hardware 
description 
304 



Convert the hardware 

description to an 
FPGA-specific Net-List 
306 



Hardware target 
specific information 
310 



Compile the net list 
into an FPGA program 
file 
312 



Transfer FPGA 
program file to 
programmable 
hardware (FPGA) to 
produce programmed 
hardware equivalent to 
graphical program 
314 



FIG. 4A 



WO 99/09498 



9/25 



PCTAJS98/13040 



(Create graphical 
program 
(Step 302) 



Arrange on the screen 
a graphical program 
(block diagram) 
342 



Develop and store tree 
of data structures 
which represent the 
graphical program in 
response to graphical 
program creation 
344 



FIG. 5 



WO 99/09498 



10/25 



PCT/US98/13040 



/'Export at least a portionX 
/ of the graphical program to a\ 
I hardware description J 
\ ^ (Step 304) y 

I 

Traverse the tree of data 
structures 
362 



Translate each data structure 
into a hardware description 
364 



FIG. 6 



WO 99/09498 



11/25 



PCT7US98/13040 



Export input terminal to 
hardware description 



No 



Is data 
input from 
supervisory portion 
sxecuting on CPU?. 
402 



Yes 



Tie into data output 
from prior node 
' 404 



Create a hardware description 
of a write register with data 
and control outputs 
406 



Connect data and control 
outputs of write register to 
graphical program 
408 



FIG. 7 



WO 99/09498 



PCT/US98/13040 



12/25 



/ Export function node to \ 
I hardware description J 



Determine inputs and outputs of 
function node 
422 



Create a hardware description of 
a function block, or insert a 
reference to a pre-compiled 
function block from library, 
corresponding to function node, 
with proper number of inputs and 
outputs 
424 



Traverse input dependencies of 
the node 
426 



__ 

Create a hardware description of 
an N input AND gate with inputs 
connected to dependent inputs of 
the function node and output of 
AND gate connected to control 
input of the function block 
428 



FIG. 8 



WO 99/09498 



PCT/US98/13040 



13/25 



No 



f Export output terminal to\ 
V hardware description J 





r 


Tie into data input on 
subsequent node 
446 



Is data 
output to 
supervisory portion 
sxecuting on CPU'L 
440 



Yes 



Create a hardware description 
of a read register with data 
and control inputs 
442 



Connect outputs of prior 
node(s) to data and control 
inputs of read register 
444 



FIG. 9 



WO 99/09498 



PCT/US98/13040 



14/25 



I Export structure node \ 
( (iteration or loop structure) to ) 
V hardware description J 



Examine structure node parameters, 
e.g., iteration number, loop condition, 
period, phase delay, etc. 
462 



Insert structure node parameters in 
hardware description 
464 



Insert reference to pre-compiled 
function block corresponding to 
structure node 
466 



FIG. 10 



WO 99/09498 



PCT/US98/13040 



15/25 



(Convert node hardware 
description to a net list 
(Step 306) 



Examine function block reference 
and any node parameters in 
hardware description 
502 



Select pre-compiled function block 
net list referenced in hardware 
description 
504 



Configure pre-compiled function 
block net list with any node 
parameters 
506 



Insert net list of configured pre- 
compiled function block into net list 
being assembled 
508 



FIG. 11 



WO 99/09498 



PCT/US98/13040 



16/25 



^Convert structure node 
(iteration or loop structure) 
hardware description to 
v net list > 



Examine function block reference 
and any structure node parameters 
in hardware description 
502A 



Select pre-compiled function block 
net list referenced in hardware 
description (corresponding to 
structure node) 
504A 



Configure pre-compiled function 
block net list with structure node 
parameters 
506A 



Insert net list of configured pre- 
compiled function block into net list 
508A 



FIG. 12 



WO 99/09498 



17/25 



PCT/US98/13040 




CO 

O 

LL 



WO 99/09498 



PCT/US98/13040 



18/25 




FIG. 14 



WO 99/09498 



19/25 



PCT7US98/13040 




WO 99/09498 



PCT/US98/13040 



20/25 





CO 

T — 

O 

LL 



cm 

qj CM 



8» 



* ^1 

03 CM 

•~ ml 



J? 

CO 

<U CM 



WO 99/09498 



PCT7US98/13040 



21/25 





WO 99/09498 



PCT/US98/13040 



22/25 



Diag 

CO 

E 

q3 — 



LabView Data Structures 
signals 



-cnstO- 



co 

?l — While 



CO 

.55 

T3 



CO I 

iMsr- 



s 1 — rsr 



-Diag 



signals 



CO 
CD 

o 
cz 



-1sr 

-rsr 

-continue - 
cnst-1 — 
-cnstO — 



cnstlOOO— 
cnstT 

- timer 
h period - 
L phase - 

- setpoint — 

- gain 

- a/d read 
L out- 

-d/a write 

-in — 
-scale2 A n 
-x — 
E-n— 
^L 0 ut- 




- subtract 

~ L out 
L multiply 

c/>[_ o 

§s-b- 
~ L out- 



FIG. 18 



WO 99/09498 



PCT/US98/13040 



23/25 




WO 99/09498 



PCT7US98/13040 



24/25 



o 

CN 

ej 

LL 





o 
O 



WO 99/09498 



PCT/US98/13040 



25/25 



Ohi limit 



H4M [[>>- 





150 



<> J [§ 




Olo limit 



- K31 2 t>l 



3> 



Ogain 





NI3--PH 








-I Eh 


X> 




























- R 


I 


m-l 


6>- 




16 


-*IQ 



e xample1 .vi 
e xampie1_vi 
e xample1.vi 



FIG. 21 



UN'liLKINA'ilUINAL, b£AKUH KHiFUKl 



Internal Application No 

PCT/US 98/13040 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 6 G06F17/50 



According to International Patent Classification (tPC) or to both national classification and IPC 

B. FIELDS SEARCHED 

Minimum documentation searched (classification system foiiowed by classification symbols) 

IPC 6 G06F 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practical, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category • 


Citation of document, with indication, where appropriate, of the relevant passages 


Relevant to claim No. 


X 


XIAO-YU CHEN ET AL: "Software environment 


1-7, 




for WASMII: a data driven machine with a 


15-30 




virtual hardware" 






FIELD-PROGRAMMABLE LOGIC ARCHITECTURES, 






SYNTHESIS AND APPLICATIONS. 4TH 






INTERNATIONAL WORKSHOP ON 






FIELD-PROGRAMMABLE LOGIC AND APPLICATIONS, 






FPL *94. PROCEEDINGS, FIELD-PROGRAMMABLE 






LOGIC. ARCHITECTURES, SYNTHESIS AND 






APPLICATIONS. 4TH INTERNATIONAL , pages 






208-219, XP002087124 






ISBN 3-540-58419-6, 1994, Berlin, Germany, 






Springer-Verlag, Germany 




A 


see abstract 


8-14 




see paragraph 3 






see figures 3-7 






-/-- 





Further documents are listed in the continuation of box C. 



Patent family members are listed in annex. 



0 Special categories of cited documents : 

"A" document defining the general state of the art which is not 
considered to be of particular relevance 

"E" earlier document but published on or after the International 
filing date 

"L" document which may throw doubts on priority clalm{s)or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

"O" document referring to an oral disclosure, use, exhibition or 
other means 

"P" document published prior to the international filing date but 
later than the priority date claimed 



T* later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

*X* document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

"Y" document of particular relevance; the claimed invention 
cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
In the art 

document member of the same patent family 



Date of the actual completion of the international search 

8 December 1998 


Date of mailing of the international search report 

22/12/1998 


Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patentlaan 2 
NIL - 2280 HV Rljswijk 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 


Authorized officer 

Guingale, A 



Form PCT/ISA/210 (second sheet) (July 1992) 



USTUKINATIUMAL SEARCH REPORT 



Internatic Application No 

PCT/US 98/13040 



C(Continuation) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ■ Citation of document, with indlcatlon,where appropriate, of the relevant passages 



Relevant to claim No. 



WO 94 10627 A (GIGA OPERATIONS CORP 
; TAYLOR BRAD (US); DOWLING ROBERT (US)) 
11 May 1994 

see page 8, line 5 - line 11 

see page 35, line 6 - page 43, line 2; 

figures 17-30 

EDWARDS M D ET AL: "SOFTWARE ACCELERATION 
USING PROGRAMMABLE HARDWARE DEVICES" 
IEE PROCEEDINGS: COMPUTERS AND DIGITAL 
TECHNIQUES, 

vol. 143, no. 1, 1 January 1996, pages 
55-63, XP000554820 

see page 58, column 1, line 2 - page 59, 
column 2, line 8; figures 2-5 

LEESER M ET AL: "HIGH LEVEL SYNTHESIS AND 
GENERATING FPGAS WITH THE BEDROC SYSTEM" 
JOURNAL OF VLSI SIGNAL PROCESSING, 
vol. 6, no. 2, 1 August 1993, pages 
191-214, XP000380758 
see paragraph 2 
see page 196, column 1, 
see page 198, column 1, 
see page 199, column 1, 
2, line 6; figures 5,7 



line 25 - line 34 
line 14 - line 51 
line 21 - column 



WO 94 15311 A (XILINX INC) 7 July 1994 



see page 7, line 27 - page 9, line 21; 
figure 5 



1-4, 

16-25, 

27-30 



1-4, 

16-24, 

27-30 



1-5,16, 

19-24, 

26,29,30 



1-5, 

10-16, 

19, 

21-24, 
26,29 



Form PCT/ISA/210 (continuation of second sheet) (July 1992) 



Info,, .atlon on patent family members 



Internatlc application No 

PCT/US 98/13040 



Patent document 
cited in search report 


Publication 
date 


Patent family 
member(s) 


Publication 
date 


Lift o^inco7 A 




us 


5535342 


A 


flQ— 07-1 QQfi 

U7 U/ 1 J3U 






AU 


5458194 


A 


tt uo i77f 






CA 


2148813 


A 


11 UO 1 J7H 






EP 


0746812 


A 


11-1 9-1 QQR 

ii i£ iyyo 






JP 


8504285 


T 








AU 


5593594 


A 


tH U3 1774 






CA 


2148814 


A 


11 UO 1774 






EP 


0667010 


A 


1 6-flfl-l QQH 

ID UO 1773 






JP 


8504514 


T 


In UO 1770 






WO 


9410624 


A 


11-05-1994 






us 


5497498 


A 


05-03-1996 






us 


5603043 


A 


11-02-1997 



WO 9415311 A 07-07-1994 US 5617327 A 01-04-1997 

US 5691912 A 25-11-1997 



Form PC17ISA/21 0 (patent family annex) (July 1 992) 



